Skip to main content
Back to Dev generators

Dev

Mock Docker Compose Generator

Used by developers, writers, and creators worldwide.

A mock Docker Compose generator saves you from rewriting the same boilerplate every project: service definitions, named volumes, health checks, and dependency ordering. Pick your database — Postgres, MySQL, MongoDB, or none — toggle Redis caching, and set your app port. The output is a ready-to-paste docker-compose.yml with correct health-check commands for each database, a `depends_on` condition so your app waits for the database to pass before starting, and sensible environment variable defaults you can swap before committing. Useful for onboarding new team members, spinning up demo projects, or just avoiding the fifteen-minute config detour when you want to start coding.

Loading usage…

Free forever — no account required

How to use

  1. Choose your options above
  2. Click Generate
  3. Copy your result

Detailed instructions

  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 API with a Postgres database in under two minutes
  • •Generating a reproducible dev environment YAML to commit alongside a new team member's onboarding docs
  • •Creating a runnable docker-compose.yml for a tutorial or Hashnode blog post readers can clone and start immediately
  • •Spinning up a throwaway MongoDB instance with Redis cache for a prototype without installing either natively
  • •Replacing a conflicting local MySQL install with a containerized version on a custom port to avoid collisions

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 run the generated docker-compose.yml file

Save the output as `docker-compose.yml` in your project root, then run `docker compose up -d` from that directory. The `-d` flag runs all containers in the background. Use `docker compose logs -f` to tail output, and `docker compose down` to stop everything — add `-v` if you also want to wipe the named volumes.

are the passwords in the generated file safe to commit to git

No — the defaults are fine for local development only. Before committing, replace hardcoded values with references like `${DB_PASSWORD}` and store the real secrets in a `.env` file added to `.gitignore`. Docker Compose reads a `.env` file from the project root automatically, so no extra tooling is needed.

what is the difference between the postgres mysql and mongodb health checks

Each database has its own readiness command: Postgres uses `pg_isready`, MySQL uses `mysqladmin ping`, and MongoDB uses `mongosh --eval 'db.runCommand({ ping: 1 })'`. Choosing the right database in the generator ensures the `depends_on: service_healthy` condition actually works, preventing your app container from crashing on first boot.