Docker-Compose

Your homelab server’s disk dies. You clone your repo onto the replacement, and everything that took weeks to get right comes back in seconds: every compose file, every bind mount, every pinned image tag. Then you bring up Immich: error while interpolating services.database.environment.POSTGRES_PASSWORD: required variable DB_PASSWORD is missing a value: err The repo has everything except the one file you deliberately kept out of it. If you keep Docker Compose stacks in git, you’ve probably gitignored your .env files, because they hold passwords and API tokens. You might have committed a .env.sample with blank values so you at least know which variables exist. That keeps secrets off GitHub, but it also leaves them out of the one place everything else is backed up. The sample can tell you that DB_PASSWORD exists. It can’t tell you what it was. So a rebuild turns into resetting database passwords and regenerating API keys, one service at a time. ...

If you’re running more than a couple of containers without version control, you’ve probably lived some version of this: you tweak a docker-compose.yaml, it breaks something, so you copy the old one to docker-compose.yaml.bak before trying again. A few edits later you’ve got docker-compose.yaml.bak2 and docker-compose.yaml.old, no idea which one was actually working, and no record of what changed between them. Putting your compose files in git fixes that. Every edit becomes a commit with a message, git diff shows you exactly what changed, and rolling back a bad config is a simple git checkout command. Pair that with a repository that’s kept separate from your container data, shared environment variables to cut down on duplication, and a small script to run everything, and your containers become a lot easier to manage. ...