Habitat vs Omnibus



Habitat and Omnibus are both great tools. They help us pack everything in a package and deliver to a system. They both can be delivered “with automation”.
For omnibus I can create an package and embed few recipes in post-install hook or via “my-package-ctl reconfigure”. For habitat I can do pretty same. The difference is that habitat has its own packages, omnibus can produce native packages.

So my question is: what the difference between this tool in general? Is habitat something like successor to omnibus? Are the any plans in Chef to rewrite chef-server installation completely with habitat?

I have also to drop some notes about my context. I have an infrastructure automated by chef. There are number of services like logging, monitoring, application services, db service, etc… Lots of stuff.
But things become too complicated when I have to create an “Installer” of that infrastructure on bare-metal on-premise infrastructure without Internet. Every cookbook expects Internet or artifacts prepared.

So I’m trying to understand how can be this achieved using Chefs’ software.

For omnibus I see the following way:

  1. Create omnibus packages for every component of my infrastructure
  2. Create repository mirror with these packages
  3. Rewrite cookbooks to use this mirror, install required packages. Here is a lot of work because most community cookbooks are trying to download things from Internet. So I have skip these steps.
  4. Post-configure software with chef-client

For habitat:

  1. Create habitat packages for every component of my infrastructure
  2. Export habitat packages to tar.gz and create distributive
  3. Spin-up an http or ftp server (or depot) with these packages
  4. Rewrite cookbook to uses archives from bootstrap server (from step 3)
  5. Post-configure software with chef-client

Maybe, I can uses both tools? Not sure. I’m in doubts.
I “googled” any article related to “habitat vs omnibus” projects, currently, without success.


I’d suggest you avoid re-inventing the wheel. Pick an already stable and existing technology, such as .deb for Debian and Ubuntu or RPM for RHEL and SuSE, and stick with it. That way packaging from upstream for most of your software is available, by default, and you’re not locked into your own personal locally maintained repos for software packages.

If you’re going to invest the time in building up packages, perhaps you can publish them in a way that the larger community can benefit from? This is why I publish my RPM’s, or RPM building tools, up on https://github.com/nkadel/.


Off the top of my head, the biggest differences:

  • Omnibus makes platform-native packages (deb/rpm/etc.), Hab uses its own format, which means:
  • Omnibus packages can be hosted in a lot of artifact servers that support those native package types (artifactory being a popular choice) whereas Hab packages have to be hosted in a habitat depot
  • Hab is more ambitious in how it deals with linker settings, which allows it to cache a lot of dependencies as separate packages, whereas Omnibus is more conservative here. As a result, with Omnibus you end up rebuilding a lot of dependencies more frequently and get slower builds.
  • Hab has a whole runtime component that enables clustering, automated upgrades (with various roll-out strategies), and a standardized interface for health checks and such.
  • Hab’s runtime component also handles configuration of the application, so for apps in Habitat you wouldn’t configure them with Chef. Chef Client would have a more limited role in just picking which apps to run with hab and maybe feeding some config data to Habitat.
  • Hab is more of a whole product and has a lot more folks working on it all the time, whereas Omnibus is more of a means to an end for us at Chef Software
  • Hab is newer and lots of things aren’t done yet. Most importantly for you, running your own Depot is a work in progress right now. It’s listed as “near term” on the public roadmap at the bottom of this page: https://www.habitat.sh/community/ – If you’re a Chef Software customer, you may be able to get early access.
  • Omnibus supports many more platforms than Hab; Hab is pretty much Linux and Windows only with the ability to run a limited version of the CLI on a Mac desktop using a Docker image to provide a Linux build environment.
  • The Hab build environment (called the “studio”) is a really fast and easy way to get a build environment that’s built-in to Hab; with Omnibus, it’s a lot more DIY to use vagrant or kitchen or whatever and generally slower.

Having used both a lot (and written a good chunk of Omnibus myself), I would advise you to go with Habitat if you can. Even if you don’t use all the features, the build speeds alone are going to be way more delightful. The things that might make you decide against it are 1) tolerance for newer software with more frequent, larger changes, and 2) whether you can wait for on-prem depot to go GA.

I can’t speak for the Habitat team on the timelines of when the on-prem Depot will be GA, but you can find them on https://forums.habitat.sh and http://slack.habitat.sh/ to discuss further.


Daniel DeLeo


I agree with this mindset, but every so often something comes along that’s worth making the jump from the established way of doing things to something that changes things up for good reasons. In my experience so far, Habitat has presented one of those times where breaking from established norms is proving worthwhile. Moving from the established paradigm where your application runs on top of a configured collection of dependencies bundled by a 3rd party, to the new paradigm Habitat creates where the application drives everything, eliminates entire classes of problems we just assumed were necessary pain and spent decades building bandaids like Vagrant and to an extent even the broader Docker ecosystem for.

Unfortunately it takes going through the full motions with it a couple of times before you can really wrap your head around the difference…which might be a big barrier for you in rolling it out to a team. I think that one sacrificial pioneer on a team is all you need though; once you get some components of your team’s system working under Habitat it becomes really easy to demonstrate its benefits and for others to pick up and increment on.


Omnibus was designed for us to package native binaries in one blob containing dependencies like the full ruby stack and openssl.

The real problem was RHEL5 and its ruby-1.8.5 which chef-client couldn’t run on at all, and even the ruby 1.9.2 in RHEL6 was broken and segfaulted constantly. We needed to be able to blow out a consistent latest-rev ruby 1.9.3 to RHEL5/6 and Ubuntu 10.04/12.04, Solaris and Windows (and now AIX, SuSE, FreeBSD, a bunch of different architectures and whatever I’ve forgotten). We went down the road of trying to build native packages for RHEL5 to get modern ruby on it, but were never remotely fully successful. The omnibus packaging system is the result of trying to solve that problem. If you don’t have that problem – which it sounds like you don’t – you shouldn’t really use it. It isn’t intended for any of our customers to run on production systems.

If habitat sounds like something that works for you, you should stay away from omnibus and evaluate habitat instead.