Is Your Docker Home Server Up to Date? How to Check and Update Docker Safely

Quick answer

Updating your containers is not the same thing as updating Docker Engine.

A home server can be running current Jellyfin, Sonarr and Radarr images while the Docker Engine underneath them is months behind on security and bug fixes.

Docker Engine 29.9.0, released on 8 October 2026, is now the current documented 29.x patch. It adds four HTTP/2 denial-of-service fixes in the Go runtime and related gRPC paths, on top of the image-pull, registry/TLS, Swarm and BuildKit fixes that arrived in 29.8.2.

If you run Docker 29.x, review and apply 29.9.0 or a later supported patch through your normal package source. Use Docker 29.9.0 Security Update: How to Safely Update Your Home Server for the focused procedure.

For an Ubuntu home server, the safe pattern is:

1. check Docker Engine and Compose versions
2. confirm Docker’s package repository
3. inspect available package updates
4. back up Compose files and .env
5. record running containers, volumes and networks
6. update Docker Engine packages
7. restart and verify containers
8. test Jellyfin storage and playback

Why container updates are not enough

There are several separate layers in a typical Docker home server:

Ubuntu
  ↓
Docker Engine + containerd + Compose plugin
  ↓
Container images
  ↓
Jellyfin / Sonarr / Radarr / qBittorrent / other apps

These layers have different update mechanisms.

Running:

docker compose pull
docker compose up -d

updates application images referenced by the Compose project.

It does not necessarily update:

• Docker Engine
• Docker CLI
• containerd
• Docker Buildx
• Docker Compose plugin

Those are normally installed and updated through Ubuntu’s package-management system.

Step 1: Check your current Docker versions

Run:

docker version

Then:

docker compose version

Also inspect the installed packages:

dpkg -l | grep -E 'docker-ce|docker-ce-cli|containerd.io|docker-buildx-plugin|docker-compose-plugin'

Record these versions before changing anything.

A simple home-lab maintenance log can be surprisingly useful:

Date
Ubuntu version
Docker Engine version
Docker Compose version
Jellyfin image/version
Reason for update
Result

Step 2: Confirm which Docker repository you use

Docker’s official Ubuntu installation normally configures Docker’s own apt repository.

Check configured Docker sources:

grep -R "download.docker.com" /etc/apt/sources.list /etc/apt/sources.list.d/ 2>/dev/null

Then inspect the package source and available version:

apt-cache policy docker-ce docker-ce-cli containerd.io docker-compose-plugin

This tells you:

• which version is installed
• which version is currently offered
• which repository would supply it

If your Docker installation came from a different package source, do not blindly switch package families during a routine security update. First understand how the server was installed.

Step 3: Check for available updates without installing them

Refresh package metadata:

sudo apt update

Then list upgradeable packages:

apt list --upgradable 2>/dev/null

Filter Docker-related packages:

apt list --upgradable 2>/dev/null | grep -Ei 'docker|containerd'

This is a useful monthly check even when there is no headline vulnerability.

Step 4: Back up the configuration that rebuilds your server

Before updating Docker itself, protect the files that describe your stacks.

For each Compose project, back up:

compose.yaml
docker-compose.yml
.env

Also record where bind-mounted configuration lives.

Inspect a container’s mounts:

docker inspect jellyfin \
  --format '{{range .Mounts}}{{println .Type "|" .Source "->" .Destination}}{{end}}'

Do the same for other important services.

The container image is replaceable. Your persistent configuration, databases and Compose definitions are not.

Step 5: Record the working Docker state

Before patching, capture evidence of the current setup.

Running containers

docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'

Compose projects

docker compose ls

Volumes

docker volume ls

Networks

docker network ls

Disk use

docker system df

For a Jellyfin server, also test that the media path is visible before the update:

docker exec jellyfin find /media -maxdepth 3 -type f | head

Replace /media with your actual container media path.

Step 6: Update Docker Engine on Ubuntu

If Docker was installed from Docker’s official Ubuntu repository, the relevant packages commonly include:

docker-ce
docker-ce-cli
containerd.io
docker-buildx-plugin
docker-compose-plugin

After reviewing the available versions, update using apt:

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

Package installation may restart the Docker daemon. Plan for a short interruption to running containers.

Do not do this immediately before leaving the house if the server provides services other people depend on.

Step 7: Verify Docker after the update

Check the daemon:

systemctl status docker --no-pager

Then confirm the new versions:

docker version
docker compose version

Check containers:

docker ps

If a container did not restart automatically, inspect its restart policy:

docker inspect jellyfin --format '{{.HostConfig.RestartPolicy.Name}}'

You can then start the relevant Compose project explicitly from its real project directory:

docker compose up -d

Step 8: Verify volumes and networks

A Docker Engine update should not redesign your Compose configuration, but verification is still worthwhile.

Inspect Jellyfin’s active mounts:

docker inspect jellyfin \
  --format '{{range .Mounts}}{{println .Source "->" .Destination "(" .Mode ")"}}{{end}}'

Check the media path inside the running container:

docker exec jellyfin ls -la /media

Check the application’s network attachments:

docker inspect jellyfin \
  --format '{{range $name, $value := .NetworkSettings.Networks}}{{println $name}}{{end}}'

If Jellyfin shares a Docker network with reverse proxies or companion services, make sure those services can still resolve and reach one another.

Step 9: Test Jellyfin, not just Docker

A successful docker ps result proves the container is running. It does not prove the application is healthy.

After the Engine update, verify:

• Jellyfin dashboard opens
• libraries are present
• media files remain visible
• one known Direct Play file works
• one intentional transcode works
• hardware acceleration still functions
• remote access still works if used

Check recent logs:

docker logs --since 10m jellyfin

For media visibility:

docker exec jellyfin find /media -maxdepth 3 -type f | head

If Docker is healthy but Jellyfin cannot see media, investigate mounts and permissions rather than rolling back Docker immediately.

What the current Docker security releases change

Docker Engine security fixes have continued beyond the earlier CVE-2026-17106 patch. Docker 29.8.2 fixed multiple Engine and BuildKit vulnerabilities involving image-index processing, registry connection handling, Swarm overlays and build inputs. Docker 29.9.0 then added four HTTP/2 denial-of-service fixes affecting daemon and related gRPC handling.

For most SmallGrid readers, the important lesson is not the mechanics of one CVE. It is that Docker Engine itself is infrastructure that needs patching, just like Ubuntu.

A server that receives current container images but never updates Docker Engine can accumulate security fixes, daemon bug fixes and compatibility changes underneath otherwise-current applications.

Establish a monthly Docker patch routine

A practical home-server routine can be lightweight.

Once a month:

sudo apt update
apt list --upgradable 2>/dev/null | grep -Ei 'docker|containerd'
docker version
docker compose version
docker ps

If updates are available:

1. read the relevant Docker Engine release notes
2. back up Compose and .env files
3. record important mounts
4. apply the update
5. verify Docker
6. verify Jellyfin and other services

For high-impact security fixes, patch sooner rather than waiting for the monthly window.

Avoid these common mistakes

Updating images but never Docker Engine

docker compose pull is not an operating-system package update.

Running docker system prune -a as part of routine patching

Engine patching does not require aggressive pruning. Cleanup and software updates are different maintenance jobs.

Changing Compose structure during an Engine security update

Keep the patch window narrow. Do not simultaneously rename volumes, move bind mounts and redesign networks unless that work is independently required.

Assuming a running container means the service is healthy

Always verify the application after infrastructure changes.

Recap

Docker Engine is part of the security boundary of a home server, and it needs its own update routine.

The recent CVE fix is a useful reminder to check the Engine and Compose versions beneath Jellyfin and other containers.

Back up the configuration that rebuilds your stack, record the working state, update Docker through the package source you actually use, then verify volumes, networks and applications after the daemon restarts.

That approach turns Docker patching from an occasional gamble into predictable home-lab maintenance.

Keep the permanent fix nearby

Affected SmallGrid guides