Last updated May 2026.
This guide covers where to store Docker stack files and SaaS infrastructure best practices. These workflows are sourced from real developer setups shared in the community to give you the exact configurations that work right now.
If a production server relies on docker-compose.yml files scattered across random home directories, one server failure away from disaster is all it takes. Properly storing and versioning Docker stack files is a critical aspect of SaaS infrastructure management. An organized repository structure simplifies CI/CD pipelines and guarantees disaster recovery in minutes. This guide details the exact directory layouts, GitOps strategies, and .env secret management workflows used by resilient, high-scaling engineering teams in the community.
Most teams drop a docker-compose.yml and related Dockerfiles right next to the code they describe. That works for tiny apps. As soon as there is a backend, a worker, a database, and a cache, the root folder gets noisy.
Separate a dedicated infra directory
Creating an infra/ folder at the repo root gives a clear boundary. Inside you can have a compose/ subfolder for compose files, a Dockerfile for each service, and any scripts used to spin things up locally.
Source code stays focused on the language being written, while the infrastructure files sit together. It also makes it easier to add CI steps that only look at the infra/ tree.
The trade-off is a tiny extra path to remember. If you type docker compose -f docker-compose.yml up from the root, you will need to add -f infra/docker-compose.yml. Most developers get over that quickly. The clarity outweighs the extra keystroke.
When a monorepo is not your thing
If services are kept in separate repos, each repo can own its own Dockerfile and a tiny docker-compose.yml that pulls the other services from a registry. In that case, the stack lives where the code lives.
The downside is losing a single place to see the whole picture. You have to piece together the full stack from several repos. This is a hassle when you need to spin up a full local environment for debugging.
Put Docker stack files in a folder that matches the size and shape of the project. For a single repo with several services, an infra/ folder keeps things tidy. For many repos, keep the files next to the code they belong to.
Frequently Asked Questions
Q: Should I commit my .env files to my Git repository?
A: Never. Always use a secret manager like Doppler, HashiCorp Vault, or encrypted Ansible Vaults, and only commit .env.example templates to source control.
Q: What is the best GitOps tool for managing Docker Compose deployments?
A: Portainer and Watchtower are the most commonly recommended tools in the community. Portainer provides a GUI for managing stacks, while Watchtower automatically pulls and redeploys updated container images.
Q: How should I handle different configurations for development and production Docker stacks?
A: The community standard is to use a base docker-compose.yml with service definitions, and override files like docker-compose.prod.yml and docker-compose.dev.yml that adjust environment variables, volume mounts, and resource limits.
Q: Is it better to store Docker stack files in the same repo as the application code?
A: For small teams and single-service apps, yes. For larger organizations with multiple teams, a dedicated infrastructure repository gives clearer ownership boundaries and makes it easier to apply access controls to production configuration.