ToolsOps

DevOps

Docker Compose generator and validator

Pick a stack and get a modern compose.yaml with named volumes, environment variables and healthchecks, plus a .env.example. Paste an existing Compose file and get warnings about plaintext secrets, exposed database ports, :latest image tags, depends_on without a health condition and dangerous mounts. Build healthcheck blocks for Postgres, MySQL, Redis or HTTP without hunting for the syntax. The YAML and .env you paste are processed in your browser and never sent to a server.

Practical Docker Compose lint, not the official Compose Spec validator. Some advanced YAML features may not be covered.

Options
compose.yaml
services:
  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      POSTGRES_DB: '${POSTGRES_DB}'
      POSTGRES_USER: '${POSTGRES_USER}'
      POSTGRES_PASSWORD: '${POSTGRES_PASSWORD}'
    volumes:
      - 'postgres_data:/var/lib/postgresql/data'
    healthcheck:
      test: ['CMD-SHELL', 'pg_isready -U $$POSTGRES_USER -d $$POSTGRES_DB']
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 20s
volumes:
  postgres_data: null
.env.example
POSTGRES_DB=app
POSTGRES_USER=app
POSTGRES_PASSWORD=CHANGE_ME

Notes about the result

  1. info.env

    Reminder: a `.env` with real secrets must NOT be committed. Version only `.env.example`.

The YAML and `.env` content you paste are processed in your browser and are not sent to a server.

Modern Docker Compose: healthchecks, secrets and depends_on

A good compose.yaml is more than a list of services: it defines how they start, in what order they wait, and how secrets are handled. These are the decisions that avoid the most mistakes in real stacks.

Per-service healthchecks

A healthcheck lets Docker know whether a service is truly ready, not just that the process started. It is the prerequisite for depends_on to wait reliably.

  • PostgreSQL: pg_isready -U $$POSTGRES_USER -d $$POSTGRES_DB
  • MySQL: mysqladmin ping with the container's user and password
  • Redis: redis-cli ping (with -a when a password is set)
  • HTTP: wget --spider against the health endpoint

depends_on with condition: service_healthy

The short form of depends_on (a list) only guarantees start order. To wait until the dependency is healthy, use the long form with condition: service_healthy and make sure the target service has a healthcheck.

Secrets and .env.example

Never put literal passwords in compose.yaml. Use ${VARIABLE} in environment and define values in a .env that is not committed. Version only a .env.example with placeholders like CHANGE_ME so anyone knows which variables are needed.

Database ports

Publishing 5432:5432 or 3306:3306 exposes your database to the whole host network. In development, if you need to connect from outside, bind to 127.0.0.1 (127.0.0.1:5432:5432). In production, keep the database on the internal Compose network and do not publish its port.

Frequently asked questions

What does this tool generate?
A practical compose.yaml for common stacks (PostgreSQL, MySQL, MariaDB, Redis with password, Nginx, Node + Postgres, WordPress + MariaDB, Prometheus + Grafana), along with a .env.example using placeholders. It includes named volumes, interpolated environment variables and, if you enable it, healthchecks. It is not a universal production-ready Compose: it is a sensible starting point you must adapt (backups, TLS, real secrets managed outside git).
How do I add a healthcheck to Postgres or MySQL in Docker Compose?
In the Healthcheck tab choose the service kind and you get a ready-to-paste healthcheck block. Postgres uses pg_isready; MySQL uses mysqladmin ping; Redis uses redis-cli ping; HTTP services use a wget against the endpoint. Commands reference the container's own variables with $$VARIABLE (Compose turns $$ into a single $, evaluated inside the container at runtime). You can tune interval, timeout, retries and start_period.
Why does my depends_on not wait for the database to be ready?
The short form of depends_on only waits for the container to start, not for the service to be healthy. To wait until the database accepts connections you need a healthcheck on that service and depends_on with condition: service_healthy. The validator warns when a depends_on targets a service that has a healthcheck but does not use the condition, and the Node + Postgres preset already produces the correct form.
Is it safe to put passwords in compose.yaml?
It is not advisable. A plaintext password inside compose.yaml ends up in your repository and git history. The recommended practice is to reference variables with ${VARIABLE} in the environment block and define the real values in a .env file that is NOT committed (version only a .env.example with placeholders). The validator flags any literal secret as danger and shows only the affected key, never the value.
Is the validator the official Compose Spec validator?
No. It is a practical lint: it covers the common Docker Compose subset and warns about the most frequent operational mistakes (latest tag, hardcoded secrets, exposed DB ports, docker.sock mount, missing restart, etc.). Some advanced YAML features (anchors, merge keys, fragments) may not be covered. For strict validation run `docker compose config` on your machine.
Do I need the version: key in compose.yaml?
No. The version: key is obsolete in modern Docker Compose (Compose v2): it is ignored and triggers a warning. That is why the generated files omit it and start directly with services:.
Is my compose.yaml sent to a server?
No. Generation, lint and the healthcheck builder all run entirely in your browser. There are no backend calls, no Docker is executed, and nothing you paste leaves your machine. The share link only serializes the UI selection (mode, stack, healthcheck kind), never the YAML or the .env.