Docker Compose Generator
Generate a ready-to-use docker-compose.yml for popular stacks — WordPress, Laravel, Node.js + MongoDB, Django, Rails, MERN, and dev databases — with optional Redis, Adminer, and pgAdmin.
General
Database
MongoDB uses this as the initial database name only.
Services
What is a Docker Compose Generator?
A Docker Compose generator produces a ready-to-use docker-compose.yml for your stack without memorising service syntax, image tags, healthcheck commands, or volume mount paths. Docker Compose defines multi-container applications declaratively - services, networks, and volumes all in one file - so the entire stack can be started with a single docker compose up -d.
Presets explained
WordPress pairs Nginx with PHP-FPM 8.2 and MySQL 8.0, sharing a named volume for the application code. Laravel uses PHP-FPM 8.3 and adds Redis for queue workers and caching. Node.js + MongoDB and MERN Stack run a Node 20 container alongside MongoDB 7 with a named volume for node_modules to avoid host filesystem performance issues. Django runs Gunicorn behind Nginx against PostgreSQL 16. Rails runs Puma behind Nginx with PostgreSQL and Redis (for Action Cable and Sidekiq). Dev Database exposes PostgreSQL directly on the host port and optionally adds pgAdmin for a browser-based SQL client.
Frequently Asked Questions
Why is there no version: key?
The version field was removed from the Compose specification in 2023. Modern versions of Docker Compose (v2+) parse the file without it. Including it is now unnecessary and generates a deprecation warning. If you need to target an older Docker Engine, add version: "3.9" at the top.
What does condition: service_healthy mean?
It tells Docker Compose to wait until the database container passes its healthcheck before starting the application service. Without this, the app may start before MySQL or PostgreSQL is ready to accept connections, causing startup crashes. The healthcheck polls mysqladmin ping or pg_isready every 10 seconds.
Why use named volumes instead of bind mounts for the database?
Named volumes (db_data:/var/lib/mysql) are managed by Docker and survive container restarts and recreations. Bind mounts (./data:/var/lib/mysql) can cause permission issues on Linux because the host user UID may not match the container's database process UID. Named volumes avoid this entirely.
Why is there a separate node_modules volume?
Mounting the entire project directory into a Node.js container (.:/app) would expose the host's node_modules - which may be compiled for macOS or Windows - inside a Linux container. The named volume at /app/node_modules overrides that path with a Docker-managed volume, so npm install inside the container always has Linux-compatible binaries.
How do I set secrets securely instead of plain-text passwords?
For development, plain-text passwords in environment: blocks are acceptable. For production, use Docker secrets or an environment variable file: create a .env file alongside docker-compose.yml and reference variables with ${DB_PASSWORD}. Compose automatically reads .env when it is present.
What does restart: unless-stopped do?
It tells Docker to automatically restart the container if it crashes or if the host reboots, but not if you explicitly stopped it with docker compose stop. This is the recommended policy for production-like services. Use restart: no for one-off containers like migrations.