A multiarchitecture container image for running Python with Gunicorn and Uvicorn.

For this container the latest version of gunicorn is always used, and the tags represent the uvicorn version.

• python-gunicorn-uvicorn
  • Benefits
    • Multi Architecture Builds
    • Small Images via Multi Stage Builds
    • No Rate Limits
    • Rapid Building of New Versions
    • Regular Updates
  • How To
    • Using the Full Image
    • Using the Slim Image
    • Copy Just the Packages
    • Add Your App
    • PreStart Script
  • Environmental Variables
    • PORT
    • WORKERS
    • LOG_LEVEL
    • MODULE_NAME
    • VARIABLE_NAME
    • APP_MODULE
    • PRE_START_PATH
    • RELOAD
    • GUNICORN_EXTRA_FLAGS
    • UVICORN_EXTRA_FLAGS
  • Python Versions
  • Image Variants
    • Full
    • Slim
  • Architectures
  • Sponsorship
  • Tags
    • Older Tags

Every tag in this repository supports these architectures:

• linux/amd64
• linux/arm64
• linux/arm/v7

All libraries are compiled in one image before being moved into the final published image. This keeps all of the build tools out of the published container layers.

This project uses the Github Container Registry to store images, which have no rate limiting on pulls (unlike Docker Hub).

Within 30 minutes of a new release to uvicorn on PyPI builds will kick off for new containers. This means new versions can be used in hours, not days.

Containers are rebuilt weekly in order to take on the security patches from upstream containers.

The Full Images use the base Python Docker images as their parent. These images are based off of Ubuntu and contain a variety of build tools.

To pull the latest full version:

docker pull ghcr.io/multi-py/python-gunicorn-uvicorn:py3.12-LATEST

To include it in the dockerfile instead:

FROM ghcr.io/multi-py/python-gunicorn-uvicorn:py3.12-LATEST

The Slim Images use the base Python Slim Docker images as their parent. These images are very similar to the Full images, but without the build tools. These images are much smaller than their counter parts but are more difficult to compile wheels on.

To pull the latest slim version:

docker pull ghcr.io/multi-py/python-gunicorn-uvicorn:py3.12-slim-LATEST

To include it in the dockerfile instead:

FROM ghcr.io/multi-py/python-gunicorn-uvicorn:py3.12-slim-LATEST

It's also possible to copy just the Python packages themselves. This is particularly useful when you want to use the precompiled libraries from multiple containers.

FROM python:3.12

COPY --from=ghcr.io/multi-py/python-gunicorn-uvicorn:py3.12-slim-LATEST /usr/local/lib/python3.12/site-packages/* /usr/local/lib/python3.12/site-packages/

By default the startup script checks for the following packages and uses the first one it can find-

• /app/app/main.py
• /app/main.py

If you are using pip to install dependencies your dockerfile could look like this-

FROM ghcr.io/multi-py/python-gunicorn-uvicorn:py3.12-0.34.0

COPY requirements /requirements
RUN pip install --no-cache-dir -r /requirements
COPY ./app app

When the container is launched it will run the script at /app/prestart.sh before starting the uvicorn service. This is an ideal place to put things like database migrations.

The port that the application inside of the container will listen on. This is different from the host port that gets mapped to the container.

The number of workers to launch. A good starting point is 4 processes per core (defaults to 4).

The uvicorn log level. Must be one of the following:

• critical
• error
• warning
• info
• debug
• trace

The python module that uvicorn will import. This value is used to generate the APP_MODULE value.

The python variable containing the ASGI application inside of the module that uvicorn imports. This value is used to generate the APP_MODULE value.

The python module and variable that is passed to uvicorn. When used the VARIABLE_NAME and MODULE_NAME environmental variables are ignored.

Where to find the prestart script.

When this is set to the string true uvicorn is launched in reload mode. If any files change uvicorn will reload the modules again, allowing for quick debugging. This comes at a performance cost, however, and should not be enabled on production machines.

This variable can be used to pass extra flags to the gunicorn command on launch. It's value is added directly to the command that is called, and has to be formatted appropriately for the command line.

This variable can be used to pass extra flags to the uvicorn command on launch. It's value is added directly to the command that is called, and has to be formatted appropriately for the command line.

This project actively supports these Python versions:

• 3.12
• 3.11
• 3.10
• 3.9
• 3.8

Like the upstream Python containers themselves a variety of image variants are supported.

The default container type, and if you're not sure what container to use start here. It has a variety of libraries and build tools installed, making it easy to extend.

This container is similar to Full but with far less libraries and tools installed by default. If yo're looking for the tiniest possible image with the most stability this is your best bet.

Every tag in this repository supports these architectures:

• linux/amd64
• linux/arm64
• linux/arm/v7

If you get use out of these containers please consider sponsoring me using Github!

• Recommended Image: ghcr.io/multi-py/python-gunicorn-uvicorn:py3.12-0.34.0
• Slim Image: ghcr.io/multi-py/python-gunicorn-uvicorn:py3.12-slim-0.34.0

Tags are based on the package version, python version, and the upstream container the container is based on.

Older tags are left for historic purposes but do not receive updates. A full list of tags can be found on the package's registry page.