Docker Compose Part 2: Update, Back Up, and Move Your Stacks

You took part one’s promise seriously, and now you have a small fleet of Docker Compose stacks — and a new, quieter problem nobody writes tutorials about. Every one of those services is aging: updates sit unapplied because you’re not sure what docker compose pull might break, your “backup plan” is a vague sense that the data is in there somewhere, and moving a stack to a newer machine feels like open-heart surgery. This is the maintenance manual I wish part one could have ended with — update without fear, back up what you can’t re-download, and move a whole stack like it’s just files. Because it is.

A stack is three things, not one

Every bit of maintenance confidence comes from one mental picture. A running stack is three different kinds of stuff, and they have completely different replacement costs:

The recipe — your compose.yaml and .env — is two small text files you wrote. The images are big, but they’re a cache: the registry — the online image library you pulled them from, Docker Hub for most of us — will hand them back anytime. The data — named volumes and bind mounts — is the only part of the whole arrangement that exists nowhere else on Earth. Once that picture clicks, everything in this post becomes obvious: updating swaps the middle column, backing up saves the outer two, and migrating moves the outer two while the middle re-downloads itself.

I’ll use the same shape of example our Uptime Kuma post deploys — Uptime Kuma itself, a single service with one named volume — because it’s the shape most homelab stacks share.

Task 1: The update ritual

Here’s the thing that surprises everyone: docker compose up doesn’t update anything by itself. Per Docker’s own reference, up stops and recreates containers only when the service’s image or configuration changed after the container was created — and crucially, it does that preserving mounted volumes. No pull, no update. So updating is a deliberate two-step, and I’ve learned to wrap it in a small ritual:

cd /opt/stacks/uptime-kuma
docker compose pull        # fetch newer images (nothing restarts yet)
docker compose up -d       # recreate ONLY what changed, volumes preserved

The Watchtower question

Every Compose maintenance conversation eventually arrives at Watchtower, the tool that watched your containers and auto-updated them when new images appeared. So let me save you some outdated advice: the original Watchtower is gone. The containrrr/watchtower repository was archived by its owner on December 17, 2025 — it’s read-only now, receiving no updates and no security patches. The maintainers were candid: they’d stopped using Docker heavily themselves and lost the time and interest to keep it alive. They deliberately declined to crown a successor, and warned users to evaluate any fork’s code and history themselves before trusting it.

There is an actively maintained fork — nicholas-fedor/watchtower — and if you’re set on auto-updates it’s the one to evaluate. But my honest recommendation for a homelab hasn’t changed, and the archive only strengthened it: auto-updating stateful services — anything that keeps data, which in a homelab is nearly everything — was always a gamble. A tool that pulls a new major database version at 3 a.m. and recreates the container doesn’t read release notes first. The update ritual above takes five minutes; run it on a schedule you choose — a monthly “patch morning” with coffee works — and the day something breaks, you’re standing right there with a fresh backup, not asleep.

Task 2: Back up the irreplaceable third

Remember the picture: the recipe and the data are the only parts worth saving. The recipe is trivial — copy two text files. The data needs one trick, adapted from the throwaway-container approach in Docker’s own volume documentation: rather than digging around in Docker’s internal storage, you run a throwaway container that mounts the volume read-only next to a backup folder, and tars one into the other:

cd /opt/stacks/uptime-kuma
docker compose stop                  # optional but safest — a quiet copy is a clean copy

docker run --rm \
-v uptime-kuma_kuma-data:/source:ro \
-v ~/stack-backups:/backup \
busybox tar czf /backup/volume-kuma-data.tgz -C /source .

docker compose start
cp compose.yaml .env ~/stack-backups/    # the recipe rides along

Two details that matter. First, the volume’s full name is the project name plus the short name — the folder uptime-kuma plus the volume kuma-data gives uptime-kuma_kuma-data; docker compose config --volumes lists the short names if you’re unsure. Second, the stop matters most for databases: tar-ing a volume while a database writes to it can capture a mid-write mess that restores into corruption. For anything with a real database, stop the stack for the seconds the tar takes — or better, use the app’s own dump tool (pg_dump and friends) and back that up.

I’ve wrapped all of this — every volume in a stack, the recipe files, timestamps, an optional stop/start — into the Compose stack backup playbook, so a nightly cron job (Linux’s built-in scheduler) can do the worrying.

Task 3: Move a stack to a new host

Sooner or later a stack outgrows its host, or the host gets rebuilt, and here the three-things picture pays off completely: migration is just Task 2’s backup, restored somewhere else. The images never travel — the new host pulls them fresh from the registry.

rsync -av /opt/stacks/uptime-kuma youruser@10.0.0.20:/opt/stacks/
rsync -av ~/stack-backups/volume-kuma-data.tgz youruser@10.0.0.20:~/

cd /opt/stacks/uptime-kuma
docker volume create uptime-kuma_kuma-data

docker run --rm \
-v uptime-kuma_kuma-data:/target \
-v ~/:/backup:ro \
busybox tar xzf /backup/volume-kuma-data.tgz -C /target

docker compose up -d       # pulls images fresh, finds its data waiting

What’s next

Your stacks now update on your schedule, survive their own deaths, and aren’t married to their hardware. If you want more practice on a meatier example, the arr stack deployment is a multi-service Compose build these exact habits keep healthy — and the localhost trap post covers the networking mistake most likely to bite when services move.

One last nudge: every path, name, and address above was an example. If a value looks specific to one machine, it’s a placeholder to change — not a literal to copy.

Related posts:

• Your First Docker Compose Stack — part one: images, containers, ports, and volumes from zero
• Docker on Proxmox: LXC vs VM — the host these stacks live on
• Deploy the Arr Stack with Docker Compose — a real multi-service stack to practice maintenance on
• Proxmox Backup Server — the whole-host backup layer under your per-stack tars
• Measure Your Proxmox Restore RTO (Honestly) — a backup you haven’t restored is a hope, not a plan
• The Docker localhost Trap — the container-networking gotcha that strikes after migrations
• Uptime Kuma: Dead-Simple Homelab Monitoring — the example service, and the thing that tells you the migration worked