Quick answer

What this guide helps you do

Update Docker Engine on Ubuntu without combining application upgrades: inventory packages, back up persistent data, review release notes and verify every container.

Quick answer

Treat a Docker Engine update as host maintenance, not as an excuse to refresh every application container at the same time.

As of 13 August 2026, Docker Engine 29.7.2 is the latest documented 29.x patch. Version 29.6.1 fixed security issues in image and build handling, 29.6.2 fixed several BuildKit and local-source vulnerabilities, and 29.7.0 added another security fix. Review every release between your installed version and the current patch before updating.

Use this order:

record packages and containers
→ read Engine release notes
→ back up Compose files, secrets and persistent data
→ preview package changes
→ update Engine components together
→ restart and verify the daemon
→ verify each application without changing its image

Engine updates and container updates are different

Docker Engine, the Docker CLI, containerd, Buildx and the Compose plugin are host-side components. Your application images are separate.

During this maintenance window:

  • update the Docker host packages
  • leave application image references unchanged
  • do not run a broad docker compose pull
  • do not redesign networks or storage
  • do not prune rollback evidence

This separation makes failures much easier to diagnose.

Step 1: record the current installation source

cat /etc/os-release
docker version
docker compose version
apt-cache policy docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Confirm whether Docker came from Docker’s official Apt repository or Ubuntu’s distribution packages. Do not mix package families during the update.

Record the installed package versions:

dpkg-query -W 'docker*' 'containerd*' 2>/dev/null

Step 2: inventory the running workload

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'
docker compose ls
docker network ls
docker volume ls
docker system df
df -h

For each important Compose project, keep a rendered copy of its effective configuration:

docker compose config > compose-effective-before-update.yaml

Protect that file if the rendered configuration contains secrets.

Step 3: read every intervening release note

Check the official Docker Engine 29 release notes and read from the installed patch through the current patch.

The 2026 security sequence is especially relevant to hosts that:

  • use BuildKit or custom build frontends
  • build from Git sources
  • upload local sources into builds
  • use docker cp
  • pull untrusted images
  • expose the Docker API to other clients

Docker 29 also contains breaking changes and deprecations inherited from 29.0.0. If upgrading from Engine 28 or older, this is a major-version upgrade and needs a broader compatibility review than a normal 29.x patch.

Step 4: back up the recovery set

Back up:

  • Compose files
  • .env files and secrets
  • bind-mounted application data
  • named-volume data using an application-appropriate method
  • consistent database exports
  • Docker daemon configuration
  • firewall and network notes
  • GPU or USB device mappings

Record:

sudo cp -a /etc/docker /path/to/backup/etc-docker
systemctl cat docker > /path/to/backup/docker-unit.txt
docker info > /path/to/backup/docker-info.txt

Replace the destination with a verified, protected path.

Do not copy a live database and assume it is consistent. Use the application’s documented backup process or stop the affected service for a filesystem-level copy.

Step 5: check daemon configuration and health

sudo dockerd --validate --config-file=/etc/docker/daemon.json
systemctl --failed
systemctl status docker --no-pager
journalctl -u docker -b --no-pager -n 100

If /etc/docker/daemon.json does not exist, do not create one merely to run this check.

Resolve existing daemon errors before updating.

Step 6: preview the package update

Refresh package metadata:

sudo apt update
apt-cache policy docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo apt-get --simulate install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Review:

  • proposed versions
  • packages to be removed
  • packages held back
  • repository origin
  • unexpected dependency changes

If the simulation proposes removing important packages or switching package families, stop and investigate.

Step 7: choose the maintenance window

Updating Engine packages normally restarts the Docker daemon. Containers may stop or reconnect, even when live restore is configured.

Confirm restart policies:

docker inspect $(docker ps -q) --format '{{.Name}} restart={{.HostConfig.RestartPolicy.Name}}'

Schedule downtime for household services and make sure you have local or SSH access that does not depend on a container being available.

Step 8: update the Engine package set

For a host installed from Docker’s official Ubuntu repository:

sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

Read the Apt summary before confirming. This keeps the supported Engine, CLI, container runtime, Buildx and Compose plugin package set aligned.

Do not paste version-pinning syntax from an old tutorial. Available package versions and epoch strings change.

Step 9: verify Docker before touching applications

systemctl status docker --no-pager
docker version
docker compose version
docker info
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}\t{{.Ports}}'
systemctl --failed
journalctl -u docker --since '-15 minutes' --no-pager

Check that:

  • the client and daemon report expected versions
  • the daemon is active
  • existing containers returned
  • health checks settle
  • networks and volumes still exist
  • published ports are listening

Do not run hello-world on a tightly controlled production host unless pulling and starting that test image fits your policy.

Step 10: verify each service

For each important application, test:

  • login or normal access
  • existing data
  • one controlled read and write
  • database connectivity
  • DNS and outbound access
  • published ports
  • bind mounts and named volumes
  • hardware or USB devices
  • dependent-service connections

For media stacks, verify Jellyfin, Sonarr, Radarr and download-client connectivity separately.

Leave application images unchanged until Engine stability is confirmed.

Rollback planning

Apt can only install an older Docker package when that exact version is still available from a configured source or local package cache. Record candidate versions before updating, but do not assume the repository will preserve them indefinitely.

If the daemon fails:

  1. preserve the journal and package transaction details
  2. do not delete /var/lib/docker
  3. validate daemon.json
  4. check package-source consistency
  5. use Docker’s documented downgrade or recovery guidance for the affected release
  6. restore daemon configuration only when it is known to be the cause

Application data backups protect the workloads; they do not automatically repair a broken Docker package installation.

Security note for Docker 29

Docker 29.6.1, 29.6.2 and 29.7.0 all included security fixes. A host on an earlier 29.x patch should not remain pinned there without a documented compatibility reason and compensating controls.

Do not hard-code 29.6.2 as the permanent target. Update to the newest supported 29.x patch after reviewing later release notes, because later patches include both further security fixes and regression repairs.

Official sources

Recap

Update the Docker host separately from the applications it runs.

Record the package source, back up persistent state, read every intervening release note, preview Apt changes, update the supported package set together and verify each unchanged workload before considering any container-image refresh.