Guides
From Docker Compose to production
Turn a docker-compose.yml into a production architecture. Which Compose services become managed databases, caches and queues, what stays a container, and what changes for security.
A Compose file is a great description of what your app needs. It is not a production architecture: it runs everything on one host, with local volumes and published ports. Brunel reads it and designs the production equivalent.
What each service becomes
| In Compose | In production |
|---|---|
Your app (build:) | A container service with several replicas behind a load balancer |
postgres, mysql, mongodb | A managed database with backups, in a private network |
redis, memcached | A managed cache |
rabbitmq, kafka, nats | A managed queue or stream |
elasticsearch, meilisearch | A managed search service (or a container at Starter) |
minio | Object storage |
nginx, traefik | The load balancer and CDN |
Security issues Compose files often carry
Brunel's security check flags them with the file and line:
- Database ports published on every interface (
5432:5432). - Hard-coded passwords in
environment:. - Privileged containers, the host network, or the Docker socket mounted.
In the design, databases are always private (rule SEC-001) and secrets go to a secrets manager (SEC-002).
Keep Compose for development
The generated bundle includes a docker-compose.yml for local development and the Starter tier, alongside the Terraform for the real environments.
Try it
Paste a repository that has a Compose file at https://brunel.cloud/new, and open the Facts panel: every Compose service appears with its evidence.