Skip to main content

Chef Habitat Overview

Chef Habitat is a workload-packaging, orchestration, and deployment system that allows you to build, package, deploy, and manage applications and services without worrying about which infrastructure your application will deploy on, and without any rewriting or refactoring if you switch to a different infrastructure.

Habitat separates the platform-independent parts of your application—the build dependencies, runtime dependencies, lifecycle events, and application codebase—from the operating system or deployment environment that the application will run on, and bundles it into an immutable Habitat Package. The package is sent to the Chef Habitat Builder (SaaS or on-prem), which acts as a package store like Docker Hub where you can store, build, and deploy your Habitat package. Habitat Supervisor pulls packages from Habitat Builder, and will start, stop, run, monitor, and update your application based on the plan and lifecycle hooks you define in the package. Habitat Supervisor runs on bare metal, virtual machines, containers, or Platform-as-a-Service environments. A package under management by a Supervisor is called a service. Services can be joined together in a service group, which is a collection of services with the same package and topology type that are connected together across a Supervisor network.


Habitat Builder

Chef Habitat Builder acts as the core of Chef’s Application Delivery Enterprise hub. It provides a repository for all available Chef Habitat packages built by Chef and the supporting community, as well as search and an API for clients.

You can store application plans on the Chef Habitat Builder SaaS where the Chef Habitat community can view and access them. You can also deploy the on-prem version of Chef Habitat Builder where you can store and maintain your apps in a secure environment.

For more information, see the Chef Habitat Builder documentation.

Habitat Package

A Habitat Package is an artifact that contains the application codebase, lifecycle hooks, and a manifest that defines build and runtime dependencies of the application. The package is bundled into a Habitat Artifact (.HART) file, which is a binary distribution of a given package built with Chef Habitat. The package is immutable and cryptographically signed with a key so you can verify that the artifact came from the place you expected it to come from. Artifacts can be exported to run in a variety of runtimes with zero refactoring or rewriting.


A plan is the set of instructions, templates, and configuration files that define how you download, configure, make, install, and manage the lifecycle of the application artifact. The plan is defined in the habitat directory at the root of your project repository.

The habitat directory includes a plan file ( for Linux systems or plan.ps1 for Windows), a default.toml file, an optional config directory for configuration templates, and an optional hooks directory for lifecycle hooks. You can create this directory at the root of your application with hab plan init.

For more information, see the plan documentation.


A service is a Chef Habitat package that is run and managed by a Supervisor. Services can be joined together into a service group, which is a collection of services with the same package and topology type that are connected together across a Supervisor network.

See the services documentation for more information.

Habitat Studio

The Chef Habitat Studio is a clean, self-contained, minimal environment in which you can develop, build, and package software that is free from any upstream operating system distribution. All tools and dependencies included in the Studio are installed through Chef Habitat packages, thus preventing any unwanted dependencies from being used by your package.

See the Habitat Studio documentation for more information.

Habitat Supervisor

Chef Habitat Supervisor is a process manager that has two primary responsibilities:

  • A Supervisor runs your app’s services. It starts, stops, updates, and monitors the services according to your plan.
  • Supervisors can talk to each other. You can connect Supervisors together into a network and instruct them to send information to each other and take actions based on that information.

In the Supervisor you can define topologies for you application, such as leader-follower or standalone, or more complex applications that include databases. The supervisor also allows you to inject tunables into your application. Allowing you to defer decisions about how your application behaves until runtime.

See the Habitat Supervisor documentation for more information.

When Should I Use Chef Habitat?

Chef Habitat allows you to build and package your applications and deploy them anywhere without having to refactor or rewrite your package for each platform. Everything that the application needs to run is defined, without assuming anything about the underlying infrastructure that the application is running on.

This will allow you to repackage and modernize legacy workloads in-place to increase their manageability, make them portable, and migrate them to modern operating systems or even cloud-native infrastructure like containers.

You can also develop your application if you are unsure of the infrastructure your application will run on, or in the event that business requirements change and you have to switch your application to a different environment.

Next Steps

Additional Resources





GitHub Repositories

Edit this page on GitHub

Thank you for your feedback!


Search Results