I run several Docker containers in a small home lab and previously wrote a manually triggered script that stopped them before updating the host operating system, then started them again afterward. I originally did this because I assumed Docker itself might be upgraded during the process. Since I'm using one host without clustering or orchestration, updates currently cause all my local services to be unavailable for a few minutes. Is manually stopping the containers worthwhile? If Docker is upgraded or restarted, will it stop and restart the containers gracefully, or should I configure something differently?
3 Answers
If you need nearly uninterrupted service, the usual solution is another host that can run the workloads while the first one is patched. That can be done with clustering or orchestration, but it’s probably overkill for a small home lab. For one machine, use restart policies, keep backups, and accept a short maintenance window rather than adding a whole cluster just for updates.
There is one case where your script can make a difference: upgrading Docker itself normally stops and restarts the Docker service, which can interrupt running containers. Docker’s `live-restore` option can keep containers running while the daemon is temporarily unavailable, so enabling that in `daemon.json` may remove the need to stop them manually. Test it with your setup first, since it has limitations and doesn’t prevent downtime from a host reboot.
For a single home lab host, manually stopping everything usually isn’t necessary. If the OS update requires a reboot, the containers will go down either way. Set each container or Compose service to a restart policy such as `restart: unless-stopped` or `always`, and Docker should bring them back after the host is available again. A Docker package upgrade can restart the Docker daemon and briefly interrupt containers, but that’s generally acceptable outside of a strict uptime environment.
That’s how I handle it too. I only consider clustering or orchestration when the downtime actually matters; building a multi-host setup just to avoid a short maintenance interruption can create more work than it solves.
The important distinction is that upgrading ordinary packages while they are running doesn’t necessarily stop their processes, but upgrading the Docker daemon does restart that service. Containers may keep running only if the relevant live-restore behavior is configured.