Dev

Mock Docker Compose Generator

Scaffolding a docker-compose.yml file from scratch means writing the same boilerplate every time: service definitions, named volumes, health checks, dependency ordering, and a dozen environment variables you'll inevitably forget. This mock Docker Compose generator produces ready-to-paste compose files for common development stacks, so you can spend time on your application instead of configuration syntax. Pick your database, toggle Redis caching on or off, and set the port your app listens on — the output handles the rest. Each generated file includes health checks with retry logic, named volumes for persistent data, and sensible environment variable defaults you can swap out before committing. The service dependency chain is wired correctly: your app container waits for the database to pass its health check before starting, eliminating the race conditions that crash containers on first boot. The configs target local development but are structured close enough to production patterns that promoting them isn't a rewrite. PostgreSQL, MySQL, and MongoDB are each configured with their native health-check commands. Redis is set up with a simple ping check. Port mappings expose services on localhost so your existing tooling — database GUIs, profilers, API clients — connects without extra configuration. Use the output as a starting point you refine, not a black box you ship. Add an Nginx reverse proxy, swap the hardcoded passwords for Docker secrets, or layer in a mail-catcher service — the YAML structure is standard and easy to extend.

How to Use

  1. Select your database engine (PostgreSQL, MySQL, or MongoDB) from the Database dropdown.
  2. Set Include Redis Cache to yes if your app uses caching, or no to keep the output minimal.
  3. Enter the port number your application listens on in the App Port field (default is 3000).
  4. Click Generate to produce the docker-compose.yml output, then copy it with the copy button.
  5. Paste the file into your project root, replace placeholder passwords, and run `docker compose up -d`.

Use Cases

  • •Bootstrapping a new Node.js or Python app with a database in minutes
  • •Replacing a local Postgres install with a containerized version
  • •Creating reproducible dev environments for a new team member's onboarding
  • •Building a tutorial or blog post demo that readers can run immediately
  • •Testing a Redis caching layer without installing Redis natively
  • •Generating a base compose file to extend with Nginx or a message queue
  • •Spinning up a throwaway MongoDB instance for a spike or prototype
  • •Standardizing database port mappings across a multi-repo monorepo

Tips

  • →Change `POSTGRES_PASSWORD` to a variable reference like `${DB_PASSWORD}` and store the value in a `.env` file — it takes 30 seconds and keeps credentials out of version control.
  • →If your app container exits immediately on first run, the database health check timeout may be too short; increase the `retries` value in the healthcheck block from 5 to 10.
  • →Add a `profiles` key to the Redis service so it only starts when you explicitly run `docker compose --profile cache up`, keeping your default stack lighter during backend-only work.
  • →Map a second port for your database service (e.g., `5432:5432`) so tools like TablePlus or DBeaver can connect directly without `docker exec`.
  • →Use the generated file alongside a `Makefile` with targets like `make dev` and `make reset` — wrapping `docker compose up -d` and `docker compose down -v` makes onboarding one command.
  • →For MongoDB, uncomment or add `MONGO_INITDB_DATABASE` to auto-create your app's database on first boot, saving the manual setup step.

FAQ

How do I start services with docker-compose?

Save the output as docker-compose.yml in your project root, then run `docker compose up -d` from that directory. The `-d` flag runs containers in the background. To follow logs afterward, run `docker compose logs -f`. Stop everything with `docker compose down`, or add `-v` to also remove the named volumes.

What does the healthcheck section do in docker-compose?

Health checks tell Docker how to verify a service is actually ready, not just running. The `depends_on` condition `service_healthy` makes your app container wait until, for example, Postgres passes its `pg_isready` probe. Without this, your app often crashes on boot because it tries to connect before the database is accepting connections.

Are the passwords in the generated file safe to use?

They are fine for local development only. Never commit real credentials or use these defaults in staging or production. Replace them with environment variable references like `${DB_PASSWORD}` and store the actual values in a `.env` file that is listed in `.gitignore`. Docker Compose reads a `.env` file automatically from the project root.

Can I add more services like Nginx or Elasticsearch to the generated file?

Yes. The output is standard Docker Compose v3 syntax. Add a new entry under the `services` key following the same pattern: image, ports, environment, volumes, and an optional depends_on. Nginx, Elasticsearch, RabbitMQ, and MailHog all have official images on Docker Hub you can drop in directly.

What is the difference between postgres, mysql, and mongodb in this generator?

Each database uses its own image, environment variable names, data directory path, and health-check command. Postgres uses `pg_isready`, MySQL uses `mysqladmin ping`, and MongoDB uses `mongosh --eval 'db.runCommand({ ping: 1 })'`. Selecting the right one ensures the health check works correctly and your app's connection string matches the exposed port.

Why is Redis included as a separate toggle?

Not every project needs a cache layer, and adding Redis when you don't need it wastes memory and adds startup time. When enabled, the generator adds a Redis service with a `redis-cli ping` health check and wires it into the app container's dependency list, so the cache is confirmed ready before your app boots.

What app port should I use if another service is already running on 3000?

Change the App Port field to any unused port — 4000, 8080, and 8000 are common alternatives. The generator maps that port on your host machine to the container. You can also run `lsof -i :3000` on macOS/Linux to check whether a port is already occupied before generating.

Does this work with Docker Desktop on Windows and macOS?

Yes. The generated file uses standard Docker Compose syntax with no Linux-specific volume options. On Docker Desktop, named volumes are managed inside the Docker VM, so data persists between `docker compose down` and `docker compose up` as long as you don't pass the `-v` flag.