When you’re building a Docker image for your Python application, you’re building on top of an existing image—and there are many possible choices. There are OS images like Ubuntu and CentOS, and there are the many different variants of the python base image.

Which one should you use? Which one is better? There are many choices, and it may not be obvious which is the best for your situation.

So to help you make a choice that fits your needs, in this article I’ll go through some of the relevant criteria, and suggest some reasonable defaults that will work for most people.

What do you want from a base image?

There are a number of common criteria for choosing a base image, though your particular situation might emphasize, add, or remove some of these:

Stability: You want a build today to give you the same basic set of libraries, directory structure, and infrastructure as a build tomorrow, otherwise your application will randomly break.

You want a build today to give you the same basic set of libraries, directory structure, and infrastructure as a build tomorrow, otherwise your application will randomly break. Security updates: You want the base image to be well-maintained, so that you get security updates for the base operating system in a timely manner.

You want the base image to be well-maintained, so that you get security updates for the base operating system in a timely manner. Up-to-date dependencies: Unless you’re building a very simple application, you will likely depend on operating system-installed libraries and applications (e.g. a compiler). You’d like them not to be too old.

Unless you’re building a very simple application, you will likely depend on operating system-installed libraries and applications (e.g. a compiler). You’d like them not to be too old. Extensive dependencies: For some applications less popular dependencies may be required—a base image with access to a large number of libraries makes this easier.

For some applications less popular dependencies may be required—a base image with access to a large number of libraries makes this easier. Up-to-date Python: While this can be worked around by installing Python yourself, having an up-to-date Python available saves you some effort.

While this can be worked around by installing Python yourself, having an up-to-date Python available saves you some effort. Small images: All things being equal, it’s better to have a smaller Docker image than a bigger Docker image.

The need for stability suggests not using operating systems with limited support lifetime, like Fedora or non-LTS Ubuntu releases.

Why you shouldn’t use Alpine Linux

A common suggestion for people who want small images is to use Alpine Linux, but that can lead to longer build times, smaller images, and obscure bugs.

You can see the linked article for details, but I recommend against using Alpine.

Option #1: Ubuntu LTS, CentOS, Debian

There are three major operating systems that roughly meet the above criteria (dates and release versions are accurate at time of writing; the passage of time may require slightly different choices).

Ubuntu 18.04 (the ubuntu:18.04 image) was released in April 2018, and since it’s a Long Term Support release it will get security updates until 2023.

image) was released in April 2018, and since it’s a Long Term Support release it will get security updates until 2023. Ubuntu 20.04 (the ubuntu:20.04 image) will be released in late April 2020, and since it’s a Long Term Support release it will get security updates until 2025.

image) will be released in late April 2020, and since it’s a Long Term Support release it will get security updates until 2025. CentOS 8 ( centos:8 ) was released in 2019, and will have full updates until 2024 and maintenance updates until 2029.

) was released in 2019, and will have full updates until 2024 and maintenance updates until 2029. Debian 10 (“Buster”) was released on July 6th 2019, and will be supported until 2024.

Only Ubuntu 20.04 includes the latest version of Python (until 3.9 is out, anyway), so you’ll have to install Python yourself.

Option #2: The Python Docker image

Another alternative is Docker’s own “official” python image, which comes pre-installed with multiple versions of Python ( 3.5 , 3.6 , 3.7 , 3.8 beta, etc.), and has multiple variants:

Alpine Linux, which as I explained above I don’t recommend using.

Debian Buster, with many common packages installed. The image itself is large, but the theory is that these packages are installed via common image layers that other official Docker images will use, so overall disk usage will be low.

Debian Buster slim variant. This lacks the common packages’ layers, and so the image itself is much smaller, but if you use many other Docker images based off Buster the overall disk usage will be somewhat higher.

The size benefit for Alpine isn’t even particularly compelling: the download size of python:3.8-slim-buster is 60MB, and python:3.8-alpine is 35MB, and their uncompressed on-disk size is 193MB and 109MB respectively.

So what should you use?

So as of April 2020, Debian Buster is a good operating system base:

It’s more up-to-date than ubuntu:18.04 . ubuntu:20.04 will take the lead in terms of packages being up-to-date, and it’s a Long Term Support release, so it’s a good choice too once it’s released in April 2020. It will limit you to Python 3.8 only, however, without doing a bit more work. Also, as with any new major software release, it’s probably worth waiting a month or three after its initial release for all the bugs to be fixed. It’s stable, and won’t have significant library changes. There’s less chances of weird production bugs than Alpine.

And the official Python Docker images based off of Debian Buster also give you the full range of Python releases.