Are you happy with your logging solution? Would you help us out by taking a 30-second survey? Click here


A minimal Ubuntu base image modified for Docker-friendliness

Subscribe to updates I use baseimage-docker

Statistics on baseimage-docker

Number of watchers on Github 6210
Number of open issues 22
Average time to close an issue about 2 months
Main language Python
Average time to merge a PR 11 days
Open pull requests 41+
Closed pull requests 43+
Last commit almost 2 years ago
Repo Created about 6 years ago
Repo Last Updated over 1 year ago
Size 1.63 MB
Organization / Authorphusion
Latest Release0.10.0
Page Updated
Do you use baseimage-docker? Leave a review!
View open issues (22)
View baseimage-docker activity
View on github
Fresh, new opensource launches 🚀🚀🚀
Trendy new open source projects in your inbox! View examples

Subscribe to our mailing list

Evaluating baseimage-docker for your project? Score Explanation
Commits Score (?)
Issues & PR Score (?)

A minimal Ubuntu base image modified for Docker-friendliness


Baseimage-docker only consumes 8.3 MB RAM and is much more powerful than Busybox or Alpine. See why below.

Baseimage-docker is a special Docker image that is configured for correct use within Docker containers. It is Ubuntu, plus:

  • Modifications for Docker-friendliness.
  • Administration tools that are especially useful in the context of Docker.
  • Mechanisms for easily running multiple processes, without violating the Docker philosophy.

You can use it as a base for your own Docker images.

Baseimage-docker is available for pulling from the Docker registry!

What are the problems with the stock Ubuntu base image?

Ubuntu is not designed to be run inside Docker. Its init system, Upstart, assumes that it's running on either real hardware or virtualized hardware, but not inside a Docker container. But inside a container you don't want a full system; you want a minimal system. Configuring that minimal system for use within a container has many strange corner cases that are hard to get right if you are not intimately familiar with the Unix system model. This can cause a lot of strange problems.

Baseimage-docker gets everything right. The Contents section describes all the things that it modifies.

Why use baseimage-docker?

You can configure the stock ubuntu image yourself from your Dockerfile, so why bother using baseimage-docker?

  • Configuring the base system for Docker-friendliness is no easy task. As stated before, there are many corner cases. By the time that you've gotten all that right, you've reinvented baseimage-docker. Using baseimage-docker will save you from this effort.
  • It reduces the time needed to write a correct Dockerfile. You won't have to worry about the base system and you can focus on the stack and the app.
  • It reduces the time needed to run docker build, allowing you to iterate your Dockerfile more quickly.
  • It reduces download time during redeploys. Docker only needs to download the base image once: during the first deploy. On every subsequent deploys, only the changes you make on top of the base image are downloaded.

Related resources: Website | Github | Docker registry | Discussion forum | Twitter | Blog

Table of contents

What's inside the image?


Looking for a more complete base image, one that is ideal for Ruby, Python, Node.js and Meteor web apps? Take a look at passenger-docker.

Component Why is it included? / Remarks
Ubuntu 16.04 LTS The base system.
A correct init process Main article: Docker and the PID 1 zombie reaping problem.

According to the Unix process model, the init process -- PID 1 -- inherits all orphaned child processes and must reap them. Most Docker containers do not have an init process that does this correctly. As a result, their containers become filled with zombie processes over time.

Furthermore, docker stop sends SIGTERM to the init process, which stops all services. Unfortunately most init systems don't do this correctly within Docker since they're built for hardware shutdowns instead. This causes processes to be hard killed with SIGKILL, which doesn't give them a chance to correctly deinitialize things. This can cause file corruption.

Baseimage-docker comes with an init process /sbin/my_init that performs both of these tasks correctly.
Fixes APT incompatibilities with Docker See
syslog-ng A syslog daemon is necessary so that many services - including the kernel itself - can correctly log to /var/log/syslog. If no syslog daemon is running, a lot of important messages are silently swallowed.

Only listens locally. All syslog messages are forwarded to docker logs.

Why syslog-ng?
I've had bad experience with rsyslog. I regularly run into bugs with rsyslog, and once in a while it takes my log host down by entering a 100% CPU loop in which it can't do anything. Syslog-ng seems to be much more stable.
logrotate Rotates and compresses logs on a regular basis.
SSH server Allows you to easily login to your container to inspect or administer things.

SSH is disabled by default and is only one of the methods provided by baseimage-docker for this purpose. The other method is through docker exec. SSH is also provided as an alternative because docker exec comes with several caveats.

Password and challenge-response authentication are disabled by default. Only key authentication is allowed.
cron The cron daemon must be running for cron jobs to work.
runit Replaces Ubuntu's Upstart. Used for service supervision and management. Much easier to use than SysV init and supports restarting daemons when they crash. Much easier to use and more lightweight than Upstart.
setuser A tool for running a command as another user. Easier to use than su, has a smaller attack vector than sudo, and unlike chpst this tool sets $HOME correctly. Available as /sbin/setuser.
install_clean A tool for installing apt packages that automatically cleans up after itself. All arguments are passed to apt-get -y install --no-install-recommends and after installation the apt caches are cleared. To include recommended packages, add --install-recommends.

Baseimage-docker is very lightweight: it only consumes 8.3 MB of memory.

Wait, I thought Docker is about running a single process in a container?

The Docker developers advocate the philosophy of running a single logical service per container. A logical service can consist of multiple OS processes.

Baseimage-docker only advocates running multiple OS processes inside a single container. We believe this makes sense because at the very least it would solve the PID 1 problem and the syslog blackhole problem. By running multiple processes, we solve very real Unix OS-level problems, with minimal overhead and without turning the container into multiple logical services.

Splitting your logical service into multiple OS processes also makes sense from a security standpoint. By running processes as different users, you can limit the impact of vulnerabilities. Baseimage-docker provides tools to encourage running processes as different users, e.g. the setuser tool.

Do we advocate running multiple logical services in a single container? Not necessarily, but we do not prohibit it either. While the Docker developers are very opinionated and have very rigid philosophies about how containers should be built, Baseimage-docker is completely unopinionated. We believe in freedom: sometimes it makes sense to run multiple services in a single container, and sometimes it doesn't. It is up to you to decide what makes sense, not the Docker developers.

Does Baseimage-docker advocate fat containers or treating containers as VMs?

There are people who think that Baseimage-docker advocates treating containers as VMs because Baseimage-docker advocates the use of multiple processes. Therefore, they also think that Baseimage-docker does not follow the Docker philosophy. Neither of these impressions are true.

The Docker developers advocate running a single logical service inside a single container. But we are not disputing that. Baseimage-docker advocates running multiple OS processes inside a single container, and a single logical service can consist of multiple OS processes.

It follows that Baseimage-docker also does not deny the Docker philosophy. In fact, many of the modifications we introduce are explicitly in line with the Docker philosophy. For example, using environment variables to pass parameters to containers is very much the Docker way, and providing a mechanism to easily work with environment variables in the presence of multiple processes that may run as different users.

Inspecting baseimage-docker

To look around in the image, run:

docker run --rm -t -i phusion/baseimage:<VERSION> /sbin/my_init -- bash -l

where <VERSION> is one of the baseimage-docker version numbers.

You don't have to download anything manually. The above command will automatically pull the baseimage-docker image from the Docker registry.

Using baseimage-docker as base image

Getting started

The image is called phusion/baseimage, and is available on the Docker registry.

# Use phusion/baseimage as base image. To make your builds reproducible, make
# sure you lock down to a specific version, not to `latest`!
# See for
# a list of version numbers.
FROM phusion/baseimage:<VERSION>

# Use baseimage-docker's init system.
CMD ["/sbin/my_init"]

# ...put your own build instructions here...

# Clean up APT when done.
RUN apt-get clean && rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/*

Adding additional daemons

You can add additional daemons (e.g. your own app) to the image by creating runit entries. You only have to write a small shell script which runs your daemon, and runit will keep it up and running for you, restarting it when it crashes, etc.

The shell script must be called run, must be executable, and is to be placed in the directory /etc/service/<NAME>.

Here's an example showing you how a memcached server runit entry can be made.

In (make sure this file is chmod +x):

# `/sbin/setuser memcache` runs the given command as the user `memcache`.
# If you omit that part, the command will be run as root.
exec /sbin/setuser memcache /usr/bin/memcached >>/var/log/memcached.log 2>&1

In Dockerfile:

RUN mkdir /etc/service/memcached
COPY /etc/service/memcached/run
RUN chmod +x /etc/service/memcached/run

Note that the shell script must run the daemon without letting it daemonize/fork it. Usually, daemons provide a command line flag or a config file option for that.

Running scripts during container startup

The baseimage-docker init system, /sbin/my_init, runs the following scripts during startup, in the following order:

  • All executable scripts in /etc/my_init.d, if this directory exists. The scripts are run in lexicographic order.
  • The script /etc/rc.local, if this file exists.

All scripts must exit correctly, e.g. with exit code 0. If any script exits with a non-zero exit code, the booting will fail.

Important note: If you are executing the container in interactive mode (i.e. when you run a container with -it), rather than daemon mode, you are sending stdout directly to the terminal (-i interactive -t terminal). If you are not calling /sbin/my_init in your run declaration, /sbin/my_init will not be executed, therefore your scripts will not be called during container startup.

The following example shows how you can add a startup script. This script simply logs the time of boot to the file /tmp/boottime.txt.


date > /tmp/boottime.txt

In Dockerfile:

RUN mkdir -p /etc/my_init.d
COPY /etc/my_init.d/
RUN chmod +x /etc/my_init.d/

Shutting down your process

/sbin/my_init handles termination of children processes at shutdown. When it receives a SIGTERM it will pass the signal onto the child processes for correct shutdown. If your process is started with a shell script, make sure you exec the actual process, otherwise the shell will receive the signal and not your process.

/sbin/my_init will terminate processes after a 5 second timeout. This can be adjusted by setting environment variables:

# Give children processes 5 minutes to timeout
# Give all other processes (such as those which have been forked) 5 minutes to timeout

Environment variables

If you use /sbin/my_init as the main container command, then any environment variables set with docker run --env or with the ENV command in the Dockerfile, will be picked up by my_init. These variables will also be passed to all child processes, including /etc/my_init.d startup scripts, Runit and Runit-managed services. There are however a few caveats you should be aware of:

  • Environment variables on Unix are inherited on a per-process basis. This means that it is generally not possible for a child process to change the environment variables of other processes.
  • Because of the aforementioned point, there is no good central place for defining environment variables for all applications and services. Debian has the /etc/environment file but it only works in some situations.
  • Some services change environment variables for child processes. Nginx is one such example: it removes all environment variables unless you explicitly instruct it to retain them through the env configuration option. If you host any applications on Nginx (e.g. using the passenger-docker image, or using Phusion Passenger in your own image) then they will not see the environment variables that were originally passed by Docker.
  • We ignore HOME, SHELL, USER and a bunch of other environment variables on purpose, because not ignoring them will break multi-user containers. See -- A workaround for setting the HOME environment variable looks like this: RUN echo /root > /etc/container_environment/HOME. See

my_init provides a solution for all these caveats.

Centrally defining your own environment variables

During startup, before running any startup scripts, my_init imports environment variables from the directory /etc/container_environment. This directory contains files named after the environment variable names. The file contents contain the environment variable values. This directory is therefore a good place to centrally define your own environment variables, which will be inherited by all startup scripts and Runit services.

For example, here's how you can define an environment variable from your Dockerfile:

RUN echo Apachai Hopachai > /etc/container_environment/MY_NAME

You can verify that it works, as follows:

$ docker run -t -i <YOUR_NAME_IMAGE> /sbin/my_init -- bash -l
*** Running bash -l...
# echo $MY_NAME
Apachai Hopachai

Handling newlines

If you've looked carefully, you'll notice that the 'echo' command actually prints a newline. Why does $MY_NAME not contain a newline then? It's because my_init strips the trailing newline. If you intended on the value having a newline, you should add another newline, like this:

RUN echo -e "Apachai Hopachai\n" > /etc/container_environment/MY_NAME

Environment variable dumps

While the previously mentioned mechanism is good for centrally defining environment variables, itself does not prevent services (e.g. Nginx) from changing and resetting environment variables from child processes. However, the my_init mechanism does make it easy for you to query what the original environment variables are.

During startup, right after importing environment variables from /etc/container_environment, my_init will dump all its environment variables (that is, all variables imported from container_environment, as well as all variables it picked up from docker run --env) to the following locations, in the following formats:

  • /etc/container_environment
  • /etc/ - a dump of the environment variables in Bash format. You can source the file directly from a Bash shell script.
  • /etc/container_environment.json - a dump of the environment variables in JSON format.

The multiple formats make it easy for you to query the original environment variables no matter which language your scripts/apps are written in.

Here is an example shell session showing you how the dumps look like:

$ docker run -t -i \
  --env FOO=bar --env HELLO='my beautiful world' \
  phusion/baseimage:<VERSION> /sbin/my_init -- \
  bash -l
*** Running bash -l...
# ls /etc/container_environment
# cat /etc/container_environment/HELLO; echo
my beautiful world
# cat /etc/container_environment.json; echo
{"TERM": "xterm", "container": "lxc", "HOSTNAME": "f45449f06950", "HOME": "/root", "PATH": "/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin", "FOO": "bar", "HELLO": "my beautiful world"}
# source /etc/
# echo $HELLO
my beautiful world

Modifying environment variables

It is even possible to modify the environment variables in my_init (and therefore the environment variables in all child processes that are spawned after that point in time), by altering the files in /etc/container_environment. After each time my_init runs a startup script, it resets its own environment variables to the state in /etc/container_environment, and re-dumps the new environment variables to and container_environment.json.

But note that:

  • modifying and container_environment.json has no effect.
  • Runit services cannot modify the environment like that. my_init only activates changes in /etc/container_environment when running startup scripts.


Because environment variables can potentially contain sensitive information, /etc/container_environment and its Bash and JSON dumps are by default owned by root, and accessible only to the docker_env group (so that any user added this group will have these variables automatically loaded).

If you are sure that your environment variables don't contain sensitive data, then you can also relax the permissions on that directory and those files by making them world-readable:

RUN chmod 755 /etc/container_environment
RUN chmod 644 /etc/ /etc/container_environment.json

System logging

Baseimage-docker uses syslog-ng to provide a syslog facility to the container. Syslog-ng is not managed as an runit service (see below). Syslog messages are forwarded to the console.

Log startup/shutdown sequence

In order to ensure that all application log messages are captured by syslog-ng, syslog-ng is started separately before the runit supervisor process, and shutdown after runit exits. This uses the startup script facility provided by this image. This avoids a race condition which would exist if syslog-ng were managed as an runit service, where runit kills syslog-ng in parallel with the container's other services, causing log messages to be dropped during a graceful shutdown if syslog-ng exits while logs are still being produced by other services.

Upgrading the operating system inside the container

Baseimage-docker images contain an Ubuntu 16.04 operating system. You may want to update this OS from time to time, for example to pull in the latest security updates. OpenSSL is a notorious example. Vulnerabilities are discovered in OpenSSL on a regular basis, so you should keep OpenSSL up-to-date as much as you can.

While we release Baseimage-docker images with the latest OS updates from time to time, you do not have to rely on us. You can update the OS inside Baseimage-docker images yourself, and it is recommended that you do this instead of waiting for us.

To upgrade the OS in the image, run this in your Dockerfile:

RUN apt-get update && apt-get upgrade -y -o Dpkg::Options::="--force-confold"

Container administration

One of the ideas behind Docker is that containers should be stateless, easily restartable, and behave like a black box. However, you may occasionally encounter situations where you want to login to a container, or to run a command inside a container, for development, inspection and debugging purposes. This section describes how you can administer the container for those purposes.

Running a one-shot command in a new container

Note: This section describes how to run a command insider a -new- container. To run a command inside an existing running container, see Running a command in an existing, running container.

Normally, when you want to create a new container in order to run a single command inside it, and immediately exit after the command exits, you invoke Docker like this:


However the downside of this approach is that the init system is not started. That is, while invoking COMMAND, important daemons such as cron and syslog are not running. Also, orphaned child processes are not properly reaped, because COMMAND is PID 1.

Baseimage-docker provides a facility to run a single one-shot command, while solving all of the aforementioned problems. Run a single command in the following manner:

docker run YOUR_IMAGE /sbin/my_init -- COMMAND ARGUMENTS ...

This will perform the following:

  • Runs all system startup files, such as /etc/my_init.d/* and /etc/rc.local.
  • Starts all runit services.
  • Runs the specified command.
  • When the specified command exits, stops all runit services.

For example:

$ docker run phusion/baseimage:<VERSION> /sbin/my_init -- ls
*** Running /etc/rc.local...
*** Booting runit daemon...
*** Runit started as PID 80
*** Running ls...
bin  boot  dev  etc  home  image  lib  lib64  media  mnt  opt  proc  root  run  sbin  selinux  srv  sys  tmp  usr  var
*** ls exited with exit code 0.
*** Shutting down runit daemon (PID 80)...
*** Killing all processes...

You may find that the default invocation is too noisy. Or perhaps you don't want to run the startup files. You can customize all this by passing arguments to my_init. Invoke docker run YOUR_IMAGE /sbin/my_init --help for more information.

The following example runs ls without running the startup files and with less messages, while running all runit services:

$ docker run phusion/baseimage:<VERSION> /sbin/my_init --skip-startup-files --quiet -- ls
bin  boot  dev  etc  home  image  lib  lib64  media  mnt  opt  proc  root  run  sbin  selinux  srv  sys  tmp  usr  var

Running a command in an existing, running container

There are two ways to run a command inside an existing, running container.

Both way have their own pros and cons, which you can learn in their respective subsections.

Login to the container, or running a command inside it, via docker exec

You can use the docker exec tool on the Docker host OS to login to any container that is based on baseimage-docker. You can also use it to run a command inside a running container. docker exec works by using Linux kernel system calls.

Here's how it compares to using SSH to login to the container or to run a command inside it:

  • Pros
    • Does not require running an SSH daemon inside the container.
    • Does not require setting up SSH keys.
    • Works on any container, even containers not based on baseimage-docker.
  • Cons
    • If the docker exec process on the host is terminated by a signal (e.g. with the kill command or even with Ctrl-C), then the command that is executed by docker exec is not killed and cleaned up. You will either have to do that manually, or you have to run docker exec with -t -i.
    • Requires privileges on the Docker host to be able to access the Docker daemon. Note that anybody who can access the Docker daemon effectively has root access.
    • Not possible to allow users to login to the container without also letting them login to the Docker host.


Start a container:

docker run YOUR_IMAGE

Find out the ID of the container that you just ran:

docker ps

Now that you have the ID, you can use docker exec to run arbitrary commands in the container. For example, to run echo hello world:

docker exec YOUR-CONTAINER-ID echo hello world

To open a bash session inside the container, you must pass -t -i so that a terminal is available:

docker exec -t -i YOUR-CONTAINER-ID bash -l

Login to the container, or running a command inside it, via SSH

You can use SSH to login to any container that is based on baseimage-docker. You can also use it to run a command inside a running container.

Here's how it compares to using docker exec to login to the container or to run a command inside it:

  • Pros
    • Does not require root privileges on the Docker host.
    • Allows you to let users login to the container, without letting them login to the Docker host. However, this is not enabled by default because baseimage-docker does not expose the SSH server to the public Internet by default.
  • Cons
    • Requires setting up SSH keys. However, baseimage-docker makes this easy for many cases through a pregenerated, insecure key. Read on to learn more.

Enabling SSH

Baseimage-docker disables the SSH server by default. Add the following to your Dockerfile to enable it:

RUN rm -f /etc/service/sshd/down

# Regenerate SSH host keys. baseimage-docker does not contain any, so you
# have to do that yourself. You may also comment out this instruction; the
# init system will auto-generate one during boot.
RUN /etc/my_init.d/

Alternatively, to enable sshd only for a single instance of your container, create a folder with a startup script. The contents of that should be

### In myfolder/ (make sure this file is chmod +x):
rm -f /etc/service/sshd/down
ssh-keygen -P "" -t dsa -f /etc/ssh/ssh_host_dsa_key

Then, you can start your container with

docker run -d -v `pwd`/myfolder:/etc/my_init.d my/dockerimage

This will initialize sshd on container boot. You can then access it with the insecure key as below, or using the methods to add a secure key. Further, you can publish the port to your machine with -p 2222:22 allowing you to ssh to instead of looking up the ip address of the container.

About SSH keys

First, you must ensure that you have the right SSH keys installed inside the container. By default, no keys are installed, so nobody can login. For convenience reasons, we provide a pregenerated, insecure key (PuTTY format) that you can easily enable. However, please be aware that using this key is for convenience only. It does not provide any security because this key (both the public and the private side) is publicly available. In production environments, you should use your own keys.

Using the insecure key for one container only

You can temporarily enable the insecure key for one container only. This means that the insecure key is installed at container boot. If you docker stop and docker start the container, the insecure key will still be there, but if you use docker run to start a new container then that container will not contain the insecure key.

Start a container with --enable-insecure-key:

docker run YOUR_IMAGE /sbin/my_init --enable-insecure-key

Find out the ID of the container that you just ran:

docker ps

Once you have the ID, look for its IP address with:

docker inspect -f "{{ .NetworkSettings.IPAddress }}" <ID>

Now that you have the IP address, you can use SSH to login to the container, or to execute a command inside it:

# Download the insecure private key
curl -o insecure_key -fSL
chmod 600 insecure_key

# Login to the container
ssh -i insecure_key root@<IP address>

# Running a command inside the container
ssh -i insecure_key root@<IP address> echo hello world

Enabling the insecure key permanently

It is also possible to enable the insecure key in the image permanently. This is not generally recommended, but is suitable for e.g. temporary development or demo environments where security does not matter.

Edit your Dockerfile to install the insecure key permanently:

RUN /usr/sbin/enable_insecure_key

Instructions for logging into the container is the same as in section Using the insecure key for one container only.

Using your own key

Edit your Dockerfile to install an SSH public key:

## Install an SSH of your choice.
COPY /tmp/
RUN cat /tmp/ >> /root/.ssh/authorized_keys && rm -f /tmp/

Then rebuild your image. Once you have that, start a container based on that image:

docker run your-image-name

Find out the ID of the container that you just ran:

docker ps

Once you have the ID, look for its IP address with:

docker inspect -f "{{ .NetworkSettings.IPAddress }}" <ID>

Now that you have the IP address, you can use SSH to login to the container, or to execute a command inside it:

# Login to the container
ssh -i /path-to/your_key root@<IP address>

# Running a command inside the container
ssh -i /path-to/your_key root@<IP address> echo hello world

The docker-ssh tool

Looking up the IP of a container and running an SSH command quickly becomes tedious. Luckily, we provide the docker-ssh tool which automates this process. This tool is to be run on the Docker host, not inside a Docker container.

First, install the tool on the Docker host:

curl --fail -L -O && \
tar xzf master.tar.gz && \
sudo ./baseimage-docker-master/

Then run the tool as follows to login to a container using SSH:


You can lookup YOUR-CONTAINER-ID by running docker ps.

By default, docker-ssh will open a Bash session. You can also tell it to run a command, and then exit:

docker-ssh YOUR-CONTAINER-ID echo hello world

Building the image yourself

If for whatever reason you want to build the image yourself instead of downloading it from the Docker registry, follow these instructions.

Clone this repository:

git clone
cd baseimage-docker

Start a virtual machine with Docker in it. You can use the Vagrantfile that we've already provided.

vagrant up
vagrant ssh
cd /vagrant

Build the image:

make build

If you want to call the resulting image something else, pass the NAME variable, like this:

make build NAME=joe/baseimage

Removing optional services

The default baseimage-docker installs syslog-ng, cron and sshd services during the build process.

In case you don't need one or more of these services in your image, you can disable its installation.

As shown in the following example, to prevent sshd from being installed into your image, set 1 to the DISABLE_SSH variable in the ./image/buildconfig file.

### In ./image/buildconfig
# ...
# Default services
# Set 1 to the service you want to disable
export DISABLE_SSH=1

Then you can proceed with make build command.


Please enjoy baseimage-docker, a product by Phusion. :-)

baseimage-docker open issues Ask a question     (View All Issues)
  • about 3 years Keyboard configuration
  • about 3 years logrotate requires a syslog user
  • about 3 years vagrant up - An error occurred during the signature verification
  • over 3 years 8.3mb coredump in /
  • over 3 years is it possible to run shell script on docker stop?
  • over 3 years cannot install php modules: invoke-rc.d: policy-rc.d denied execution
  • over 3 years service/run_script con't correct run by my_init
  • over 3 years Cannot upload files larger than a few kb with SFTP
  • over 3 years `netbase` not present in 0.9.19
  • over 3 years my_init has zombie child process [0.9.18]
  • over 3 years [16.04] debconf: delaying package configuration, since apt-utils is not installed
  • almost 4 years @reboot cron jobs not being run
  • almost 4 years Add Changelog with GitHub Releases
  • almost 4 years locale setting for debian
  • almost 4 years baseimage-docker on alpine?
  • almost 4 years Use `ARG` for optional services during `docker build`
  • almost 4 years Should setuser be more "forgiving"?
  • about 4 years List of images extending baseimage-docker
  • over 4 years Feature: Documentation/Locale Filter
  • over 4 years my_init.d scripts and run issues
  • over 4 years invoke-rc.d <service> stop fails
  • almost 5 years Cron jobs does not run because of hard links to crontab files
  • about 5 years explain why runit
  • over 5 years Add docker-scp
  • over 5 years HOME environment var ignore on version 0.9.11 and 0.9.12
  • over 5 years Document selection of syslog-ng over rsyslog
  • over 5 years Environment non ascii content
  • over 5 years Trusted build
  • over 5 years my_init should have a mechanism to wait until all Runit services are started
baseimage-docker open pull requests (View All Pulls)
  • Remove the original content has been translated
  • TERM should be something better than 'dumb' when running `docker exec -it ...`
  • configure process kill timeouts through environment with fallbacks
  • Add argument --ssh-port to my_init
  • Remove correct apt-speedup file in
  • bash completion for sv
  • Feature: Add template processing
  • fixed /proc/kmsg: permission denied in syslog-ng
  • improve the baseimage
  • Add instructions for enabling sshd on the fly without permanently enabli...
  • Use COPY instead of ADD
  • wait-for-services script
  • factor out nsenter, in favor of docker exec
  • replace insecure-key support with authorized-key support
  • Preserve /build/{,buildconfig} files.
  • Create mountpoint for Vagrant synced folder
  • Have syslog forward to docker by itself
  • Fix Python executable not found
  • Fix incorrect runit service name for syslog tail
  • Changes to upgrade this to Ubuntu-16.04
  • Added support for running the command as nobody.
  • Add additional cleanup steps to further reduce image size
  • Fix race condition in my_init causing container never to exit
  • Support for pre- and post-shutdown scripts
  • Use syslog-ng built-in pipe to forward messages
  • Using purge instead of remove in
  • Reconfigure locales and expose them in Dockerfile
  • Removing -f option of `docker tag`
  • Fix logrotate default group
  • Match logrotate and syslog configuration
  • override the logrotate.conf without `su root syslog`
  • runit policy with /etc/sv and /etc/service
  • README: "RUN chmod +x /etc/my_init.d/"
  • README: "RUN chmod +x /etc/service/memcached/run"
  • Provided a fix for cron not working out of the box.
  • fix typos for and
  • feat: allow specifying init argument defaults via environment variables
  • feat: allow users to specify an alternative init directory
  • my_init exits with 0 on SIGINT after runit is started
  • Added /etc/my_cron support
  • fixed syslog warning when using --tty as described in #468
baseimage-docker questions on Stackoverflow (View All Questions)
  • how to set ulimit / file descriptor on docker container the image tag is phusion/baseimage-docker
  • watchman not found on phusion/baseimage Docker image with ember-cli
  • How do I "dockerize" a redis service using phusion/baseimage-docker
baseimage-docker list of languages used
baseimage-docker latest release notes
0.10.0 v0.10.0

A lot of work and contributions went into this release, this is an API breaking release so we have versioned the minor version to 10.

A special thank you goes out to all who have helped work to prepare this release as well as all contributors and users of Phusion Baseimage.

We are currently working on putting automated releases into place so we will always have current Docker images pushed, keep an eye out for that!


  • Syslog messages are not forwarded #437
  • Lost log messages in docker logs #436
  • Gracefully handle syslog-ng shutdown #447


  • feat: allow users to specify an alternative init directory #410
  • Added utility #442


  • Adding more to the first sentence. #439
  • Update #444
  • Create #446


  • Remove 3 unnecessary layers from the layer count #409
  • sanitize_shenvname returns string with [0-9a-zA-Z_] characters #423
  • Evaluate if fix_pam_bug is still needed #404
  • Replaces #410 #432
  • Reflect 'latest' in image. #435
  • Use syslog-ng built-in pipe to forward messages #324
  • configured syslog-ng to log to stdout directly instead of using tail #438
  • Have syslog forward to docker by itself #287
  • Start syslog-ng before runit, and stop after runit. #425
  • Fork syslog-ng into a new process group via bash monitor mode #453
0.9.22 v0.9.22


  • shutdown_runit_services error on exiting interactive container #408
  • debconf: delaying package configuration, since apt-utils is not installed #319
  • apt-get fixes #406
  • Build failed no source package for PAM #394
  • fixes the build #395
  • Bug in my_init.shutdown_runit_services #391
  • #392
  • TypeError when stopping/exiting container [0.9.21] #398


  • Support for pre- and post-shutdown scripts #329
  • Pre and post shutdown scripts added #402
  • prepare pre and post shudown.d folders #407


  • more pep8 linting #400
  • Improve pep8 compliance #399
  • Suppress the status reports from sv -w #396
0.9.21 v0.9.21


  • Nginx fails to log to syslog #277
  • Remove KILL_PROCESS_TIMEOUT or make it modifiable #384


  • Nothing


  • [README] Fix grammar #379
  • Preserve /bd_build/{,buildconfig} files. See #188 #380
  • Correct translation of syslog-ng driver system() on Docker #382
  • Typo chinese translation #383
  • Fix kill timeouts #385
  • down wait for 7 secs this will fix it. #388
Other projects in Python