Docker Compose 5.5: native init containers, pull_policy refresh windows and digest reconciliation

Who manages Linux servers with containerized applications has probably already met Docker Compose: the tool that allows to describe, in a single YAML file, all the services that make up an application (database, backend, reverse proxy, cache) and start them with only one command. In recent months the project has released a series of updates (from version 5.3 of July 2026 to 5.5.1 of early September) that introduce some very popular features from the community of system administrators: the so-calledinit containernatives, a more refined management of image updates throughpull_policyand onereconciliation of digeststhat avoids unnecessary reboots of the container. Let's see in detail what changes and how to exploit these novelties safely.

What is a container init and why it serves

Ainit container(initialization container) is a small container that is executed before the actual service, to carry out preliminary operations: apply the migrations of a database, download configuration files, set the correct permissions on a shared folder, wait for an addiction to be ready. Before version 5.3 of Docker Compose (released on 2 July 2026), administrators had to resort to indirect solutions, such as "use and throw" services set aside in the file docker-compose.ymland connected viadepends_on, or shell scripts executed manually before booting.

With the introduction of native support, init containers are configured directly within the service through the new directivepre_start. Each step listed inpre_startis executed in a temporary container immediately after the creation of the main service but before its actual start; if one step ends with a different exit code from zero, the service does not depart, thus avoiding an application to start in an incoherent state (for example with a database not yet updated).

A practical example clarifies the operation better:

services:
  app:
    image: myapp:latest
    user: "1000:1000"
    volumes:
      - data:/data
    depends_on:
      db:
        condition: service_healthy
    pre_start:
      - command: ["./manage.py", "migrate"]
      - image: busybox
        user: root
        command: sh -c 'chown -R 1000:1000 /data'

  db:
    image: postgres:18
    healthcheck:
      test: ["CMD-SHELL", "pg_isready"]

volumes:
  data:

In this example, before the serviceapptwo steps are taken in sequence: the migration of the database through the application command itself, and the correction of permissions on the shared folder/datausing minimal imagebusybox. If you do not specify a different image, each step by default inherits the image of the main service; all steps also share the same networks and the same volumes of the service, then the files prepared during initialization are immediately visible to the definitive container. A useful detail for those who manage environments with limited resources: one steppre_startthat has not changed compared to the previous execution and that has already gone to good end is automatically jumped in successive executions.

pull_policy: smarter image updates

The Directivepull_policyexists for a long time in Docker Compose and allows you to check when an image has to be downloaded again from the registry: the most common values arealways(Always download the latest version),missing missing(Download only if the image is not present locally),♪( never download, useful in isolated environments) andbuild(constructs the image locally instead of downloading it). With version 5.5.0, released on 17 August 2026, the commandcompose pullhas become more aware of the time spent by the last update: it respects configurable refresh windows (e.g. daily, weekly or every N executions), avoiding unnecessarily reconnecting the remote registry when the image has already been verified recently. For an administrator who manages dozens of containers on multiple servers, this results in less network traffic generated by automatic controls and more predictable deployment times, especially when updates are launched by an automation pipeline or a planned cron job.

Reconciliation of digests: less unnecessary reboots

Also in version 5.5.0 a new mechanism was introducedreconciliation of images digests. In summary, Docker Compose now more accurately compares the digest (the unique footprint) of the image actually used by a container with that of the most recent available image, avoiding recreating a container when, in reality, there are no substantial changes to be applied. Who works with Docker knows how annoying it is to see a service restart without an apparent reason during a simpledocker compose up: This change reduces this kind of unnecessary interruptions. But it is good to know that, as reported in official release notes,the first timethat you performcompose upAfter upgrading to this version, some existing containers could still be recreated, because digests are revalued once with the new logic. It is therefore advisable to plan this first reboot in a maintenance window, especially for production services.

The other news of 5.5.1

The most recent version, 5.5.1 (3 September 2026), focuses mainly on minor but useful improvements in debugging:life cycle hook(the commands executed automatically at the start or shutdown of a service) now capture and show their output directly in the terminal, which simplifies the diagnosis when something goes wrong during these stages. OpenTelemetry tracking errors have also been improved when using the flag--debug, useful for those who integrate Compose in more complex observability environments. Among the bug fixes we also report better synchronization management of linked directories (functionwatch) and a stronger support to IPAM options in networking creation.

How to update Docker Compose safely

Before upgrading, it is good to check the currently installed version with the commanddocker compose version. On most Linux distributions, Docker Compose is installed as a Docker client plugin and updates with the packagedocker-compose-pluginvia system package manager (e.g.apt update && apt upgrade docker-compose-pluginon Debian and Ubuntu). Alternatively, those who have installed the plugin manually can download the latest track directly from the official release page on GitHub.

Some practical suggestions for those who administer servers in production:

Test first in a staging environment.As seen, the new mechanism of reconciliation of digest can cause the recreation of some container at the first start after the update: better discover it in a non-critical environment.
Always read official release notesbefore upgrading to production, to see if there are any behavior changes affecting your filesdocker-compose.yml.
Use the init containerto replace any external initialization scripts already in use: in addition to simplifying maintenance, this makes the application behavior more predictable and documented directly in the configuration file.
Evaluate pull_policy refresh windowsif you manage many hosts and you want to reduce the load on the company's private Docker logs.

Overall, these innovations confirm a clear trend in the evolution of Docker Compose: making it increasingly suitable for real production scenarios, reducing the need for external scripts and improving the predictability of updates, two aspects particularly appreciated by Linux systems on a daily basis.

Official sources

Docker Compose official release notes on GitHub
Official documentation Docker: Use init containers in Compose
Official documentation Docker: Docker Compose pull