Updating your containers without breaking anything

There are two ways to lose data with Docker, and automatic updates combine them both: applying a change you did not choose, at a time when you are not looking.

This guide does the opposite. You update when you decide, ten minutes a month, and you know how to go back.

First, the latest tag is the real problem

image: jellyfin/jellyfin:latest

That is not a version. It is "whatever the maintainer considers current at the moment you pull". Two consequences:

• You do not know what you are running. docker compose up -d on one machine and on another, a month apart, does not give you the same thing.
• You cannot roll back, because you do not know where you came from.

Pin it:

image: jellyfin/jellyfin:10.10.7

Nothing moves until you change that number. That is the whole idea.

For a critical component — the reverse proxy, a database — you can go further and pin the digest, which names one image and only one:

image: postgres:16.4@sha256:....

Step 1 — Know a release happened

Without automation you still need a source. Two honest options:

• Watch the repositories of your services on GitHub (Watch → Releases only). One email per release, with the release notes — which is exactly the information an automatic update throws away.
• A tool that NOTIFIES without applying: What's Up Docker or diun. They compare your images against what exists and tell you. The decision stays yours.

Step 2 — Read the release notes

This is the step everyone skips, and the one that costs. You are looking for three words: breaking, migration, manual.

A service going from 2.x to 3.x often migrates its database on first start. That migration is irreversible: dropping back a version afterwards gives you a service that refuses to start against a database it no longer understands.

This is precisely what an automatic update can do nothing about.

Step 3 — Back up FIRST

docker compose stop

Then back up the volumes — see Backing up your server. If you take one thing from this guide: a backup from before the update is what turns a failure into an inconvenience.

Stopping the containers is not optional for a database: copying the files of a Postgres that is mid-write gives you a backup that looks complete and does not restore.

Step 4 — Update

Change the version number in docker-compose.yml, then:

docker compose pull
docker compose up -d

pull downloads, up -d recreates only the containers whose image changed. The rest are left alone.

One service at a time. Six at once, and the day something breaks you have six suspects.

Step 5 — Actually check

docker compose ps
docker compose logs -f --tail=50

ps should show Up, not Restarting — a container in a restart loop gives you an unreachable service that your dashboard still reports as running.

Then open the service and do something real: start a playback, add a photo, expand an entry. A home page that renders proves very little.

Rolling back

Put the old number back in the file, then:

docker compose up -d

That is enough as long as the data has not been migrated. If it has, it is the step 3 backup you restore — which is why step 3 exists.

Why this guide argues against automation

Every tutorial recommends Watchtower. It was archived on 17 December 2025: the repository is read-only and the project itself states it is no longer maintained. Having your security patches applied by a tool that no longer receives any is a contradiction.

But even maintained, the reasoning would hold. An automatic update:

• applies an irreversible migration with nobody reading the notes;
• breaks at three in the morning, and you hear about it from someone else;
• makes diagnosis impossible — "it worked yesterday" no longer points at anything, since you changed nothing.

Ten minutes a month, service by service, with a backup behind you. Less appealing, and it holds.

Cleaning up

Old images stay on disk. After a few months:

docker image prune -a

Careful: this removes every image not used by a running container, including the ones you might want to go back to. Do it once the new version has proven itself, not the same day.

Next

• Backing up your server properly
• Setting up a reverse proxy