Docker Compose Generator
Assemble a docker-compose.yml file for your own stack
-
1Enter data
Enter content, paste text or load a file from disk. -
2Click the button
The tool will immediately process your data in the browser. -
3Get the result
Copy the finished text or save the file to your device.
return "Result ready in 0.1s";
}
Rate this tool:
Related tools
Other tools you may find usefulDocker Compose generator - a whole web stack in one file
The Docker Compose generator builds a file for a local web environment out of six blocks: a PHP-FPM application container, Nginx, MySQL or MariaDB, PostgreSQL, Redis and MailHog. Pick the services, set the HTTP port and the database version, and you get YAML with healthchecks, named volumes and passwords kept in environment variables.
What the tool puts in the file
Every selected service becomes one block under services. There is no version: field, because the Compose Specification calls it obsolete.
| Service | Image | Host port | Volume |
|---|---|---|---|
| Application (PHP-FPM) | build: . | none | bind mount |
| Nginx | nginx:1.27-alpine | chosen port | bind mount |
| MySQL / MariaDB | mysql:8.0, mysql:8.4, mariadb:10.11 | 127.0.0.1:3306 | db_data |
| PostgreSQL | postgres:16-alpine | 127.0.0.1:5432 | pg_data |
| Redis | redis:7-alpine | 127.0.0.1:6379 | redis_data |
| MailHog | mailhog/mailhog:v1.0.1 | 127.0.0.1:1025 and 8025 | — |
The application container also gets connection details: DB_HOST is db or postgres, REDIS_HOST is redis. With two databases selected the DB_* variables describe MySQL.
How to start the generated stack
- Select the services, the HTTP port and the database version. The Example button loads a typical set: application, Nginx, MySQL 8.0 and Redis on port 8080.
- Copy the result and save it as
docker-compose.ymlin your project directory. - Next to it create an
.envwithDB_PASSWORDandDB_ROOT_PASSWORD. - With the application container selected, add a
Dockerfile— the Dockerfile generator helps. - For Nginx prepare
docker/nginx/default.conf; build thelocationblock in the Nginx location block configurator. - Run
docker compose up -d. Service state comes fromdocker compose psand logs fromdocker compose logs -f.
Passwords are not written into the file
${DB_PASSWORD:?set DB_PASSWORD in .env}. The :? form marks the variable as required: without it Compose aborts and says what is missing, instead of starting a database with a password known to anyone who has seen this template.The compose file goes into the repository, the .env file does not. One YAML then serves every developer machine and CI, and credentials stay out of Git. As the variable list grows, the .env variable sorter helps.
Why depends_on alone is not enough
The short form depends_on: [db] only controls the order in which containers launch. A database container counts as started after a few hundred milliseconds, but MySQL needs a dozen seconds to initialise its data directory — long enough for the application to die on a refused connection. So every database and Redis get a healthcheck, and the application service the long form:
depends_on:
db:
condition: service_healthy
Nginx waits for the application with condition: service_started, because the PHP-FPM container has no healthcheck and a health condition would block the whole stack.
Volumes, ports and networking
Database data lands in named volumes. Such a volume survives docker compose down and does not depend on host directory permissions; only docker compose down -v removes it. The project directory is a bind mount, because in development you want code changes visible without rebuilding the image.
Database and cache ports are published on 127.0.0.1. A plain 3306:3306 listens on every interface, so on a laptop joined to public Wi-Fi it exposes the database to the world. Containers reach each other by service name on the Compose network anyway — the database host is db or postgres, never localhost.
Before you move the file to production
This template is a development environment: code mounted from the host, a database port on localhost, MailHog catching mail. In production the code goes inside the image, database ports stay unpublished, and a real provider sends the mail. A cluster needs manifests from the Kubernetes Deployment generator, and the file is worth a pass through the YAML validator, where one extra space changes everything.
Frequently asked questions
What is the difference between a Dockerfile and docker-compose.yml?
A Dockerfile is the recipe for a single image: base system, dependencies, code, start command. The docker-compose.yml file builds nothing itself — it describes which images run together, how they are wired on a network and in what order they come up. In the application service the build: . entry points back at your Dockerfile.
Why does my application not see the database?
Almost always because localhost was left in the configuration, and inside a container it means that same container, not the host. On a Compose network the database address is the service name: db for MySQL and MariaDB, postgres for PostgreSQL. The other common cause is an application starting too early — that is what service_healthy fixes.
Does database data survive removing the container?
Yes, it lives in the named volume db_data, pg_data or redis_data from the volumes section at the end of the file. Only an explicit docker compose down -v drops it.
Why is there no version field in the file?
Because the Compose Specification made it unnecessary. A line such as version: "3.8" dates back to the days when Compose had several incompatible file schemas. Today docker compose detects the schema itself and reports the field as obsolete.
MailHog is no longer maintained, what should I use instead?
Mailpit is the successor, compatible with MailHog on SMTP port 1025 and the web UI on 8025. The generator pins MailHog to v1.0.1, so the image cannot shift under you. For Mailpit, swap the image line for axllent/mailpit:latest.