minideb: a new container base image

James Westby

James Westby

Share this article

At Bitnami we are building and testing a new base image for containers: minideb. We designed the image to balance two goals, using the fact that this image is specifically for use in containers:

  • The base image should be as small as possible
  • The base image should have compatibility with as much software as possible, and as much software as possible available to easily pull into images built using the base.

Let’s look at the benefits of each of these.

Small Images

There are many advantages to having small base images for containers:

  • Smaller runtime footprint: smaller images have a smaller footprint at runtime. While the base image may be shared between containers that use the same one, often one host will be running containers using different base images.
  • Smaller storage footprint: it’s a minor effect, but smaller images take less space to store, e.g. in a registry.
  • Faster transmission: It’s faster to push and pull smaller base images. This is nice for developers, and can also be important for a cluster pulling a new image revision to deploy an update, or when migrating a container from one host to another.
  • Lower attack surface: the fewer things in the image, the lesser the attack surface, so the lower the chances that there will be a security hole that can be exploited.

Lots of people are working on building small images, either for particular use cases (e.g. staticpython) or general use (e.g. alpine).


For a general base image it is important that the image be compatible with as much software as possible.

Some base images reduce size by using components such as musl libc and busybox that are very small, but don’t have some features that are expected by other software.

To be really useful to developers you want a base image to have a large library of software available to easily integrate into images.

Our Compromise

After testing a few different approaches and looking at the contents of several base images, we came up with a compromise. We would use a Debian-based image, as it has a huge library of software just an apt-get away, and is based on glibc, but strip out as much as possible that is unlikely to be used in containers.

Removing The Surplus

In order to do this we looked at an inventory of the standard minbase Debian base generated by debootstrap. We looked at the list of packages that were installed, and picked the ones that aren't needed in containers. There were two main categories of packages that were removed:

  1. Packages for dealing with hardware. This is not usually done within a container.
  2. Packages for interactive use. While developers will often shell in to an image to debug something, we decided that developers should tolerate a less ideal experience for the benefits of a smaller image the rest of the time. If they disagree they are free to install any packages they want in their images.

Next we looked at the filesystem with all the necessary packages installed and looked at what we could remove. We decided to remove:

  • Docs, manpages, info pages.
  • Locales
  • apt caches
  • log files
  • tmp files

Some of these may again be useful during development and debugging, but can be easily accessed elsewhere, e.g. launching a full Debian image to read the manpage.

Some of the changes that we have made will break compatibility with a few of the packages in the Debian archive. For instance, we remove the init system from standard Debian, this will break any container that expects to use the init system to manage processes. If a developer using minideb finds such a case they can install the missing packages in their image.

The Result

The minideb image currently weighs in at around 50MB uncompressed. For comparison the debian library image is 123MB, the alpine image is 5MB, and the newly released amazonlinux image is 328MB.

While minideb is much larger than alpine it is a lot smaller than the standard debian image while retaining most of the compatibility.

Using The Image

If you are using docker you can use

FROM bitnami/minideb:jessie

in your Dockerfile to use minideb as your base image. The image is updated daily and includes the security repository, so pulling minideb and rebuilding your image will include any new security fixes.

There is one nice extra feature included in minideb: the install_packages command. You can use this instead of calling apt-get in your Dockerfile and it will do two things:

  1. Install the packages specified without any prompts.
  2. Keep your image smaller by removing apt caches etc. after it has finished.

If you aren't using docker, or would prefer to build the image yourself, you can find everything you need in the github repository.

What's Next?

We are going to continue testing minideb with the Bitnami application catalog. This may lead to changes to minideb, or us deciding that another base image would benefit our users more.

However, if all goes well then we will release all of our containers with a smaller base image, making Bitnami containers even better for our users.

If you want to keep up with changes to minideb you can follow the github repository and look out for other posts on this blog.