Habitat 1.6.39 Released!

We are happy to announce the release of Habitat 1.6.39!

With this release, the Supervisor can now be configured with a file,
rather than solely through environment variables and commandline
options. This should provide users with a lot more flexibility for how
they deploy and manage Habitat Supervisors. Check out the
docs for
the details.

Also in this release, our Docker exporter has a few new features.

First of all, it has been renamed! While you can still call it as hab pkg export docker, the preferred way to call it going forward is hab pkg export container.

The reason it has been renamed is because now you have the option of
not using Docker at all! Now, with the new --engine option, you have
the ability to use Buildah as a backend for
creating container images. This means that you will be able to create
container images without involving the Docker daemon, and thus without
the security implications of potentially providing root access to your
system. While this isn’t usually an issue on developer workstations,
it can be a big deal on shared infrastructure and CI systems.

As Buildah only works on Linux, this ability is thus necessarily
limited to Linux platforms. To enable this functionality, use the new
--engine option:

hab pkg export container core/redis --engine=buildah

The default engine remains Docker. While the --engine option is
technically available on Windows, docker is the only allowed value.

One important thing to note is that Docker and Buildah store their
local images in different locations. This means that, despite the
tools creating compatible images, you will not be able to (directly)
run a Buildah-built container under Docker, in contrast to what your
typical “export a container, run that container” development
workflow might be. There are two options, though.

First, use podman. Podman and Buildah are sister
projects in an overall effort to tease apart the features of the
Docker monolith. While Buildah handles construction of images, Podman
handles the running of those images as containers (that is, buildah
is to docker build as podman is to docker run). As such, Podman
looks for images in the same place that Buildah creates them. Like
Buildah, Podman also does not require a privileged account to
run. And, as a bonus, you can essentially use podman as an alias for

The second alternative is to use buildah to export your image to
your Docker daemon. This effectively copies your image from “Buildah
space” to “Docker space”.

buildah push core/redis:TAG docker-daemon:core/redis:TAG

(where TAG is the tag of the image you want to transfer)

Since this command does interact with a Docker daemon, you will
require suitable privileges to execute this operation.

It should be noted that these approaches are not required if you wish
to export a container and push the generated images to a remote
repository as part of the same hab pkg export container
invocation. The Buildah engine implementation knows how to push to
remote repositories without any additional effort on the part of the

Also be aware that this feature does not currently work from within a
Studio. That will come soon, but we wanted to get this feature out for
people to start experimenting with.

Be sure to read on for additional changes! If you just want the
binaries, head on over to Install
. Thanks!

1.6.39 (2020-05-28)

Full Changelog

Behavioral Changes

New Features & Enhancements

Merged Pull Requests