AnyTool
Your files never leave your device. All processing happens locally in your browser.

How do I generate a docker-compose.yml file?

Add services from a catalog of common images — Nginx, Node, Python, PHP, Postgres, MySQL, MongoDB, Redis, RabbitMQ, WordPress, Adminer, pgAdmin and more — each pre-filled with sensible ports, environment variables, volumes and a healthcheck. Edit the image and tag, ports, env vars, volumes, depends_on, restart policy and healthcheck per service, or pick a one-click stack preset such as WordPress + MySQL or Node + Postgres + Redis. Valid, correctly-indented docker-compose.yml is written live as you type — no obsolete version: key (Compose v2). Copy it or download docker-compose.yml. Everything is built in your browser; nothing is uploaded.

  • Service catalog of 20+ common images with sensible defaults
  • Six wired-together stack presets (WordPress, MERN, LAMP, Node+Postgres+Redis, …)
  • Per-service image+tag, ports, environment, volumes, depends_on, restart, healthcheck, command
  • Named volumes and a shared bridge network collected into top-level volumes: and networks:
  • Compose v2 — no obsolete version: key; depends_on upgrades to condition: service_healthy
  • Copy or download docker-compose.yml — 100% client-side, nothing uploaded

What is

docker-compose.yml

A docker-compose.yml file is a declarative YAML manifest that defines a multi-container application for Docker Compose. Its top-level services: map describes each container — the image, ports, environment, volumes, networks, depends_on order and restart policy — while top-level volumes: and networks: declare the named volumes and networks the services share. Modern Compose v2 treats the old version: key as obsolete and ignores it.

Container Orchestration

Related terms

Docker Composeserviceimagenamed volumebridge networkdepends_onhealthcheck

Frequently Asked Questions

No. Docker Compose v2 treats the top-level version: key as obsolete, so a modern docker-compose.yml starts straight with services:.

Older Compose files began with a line like version: "3.8", but the Compose Specification used by Docker Compose v2 made that key obsolete — current versions ignore it and may print a warning if it is present. A modern file starts directly with the services: map and adds top-level volumes: and networks: blocks only when they are needed. This generator follows Compose v2 and never emits a version: key, so the output is current and warning-free.

depends_on only waits for a container to start; add a healthcheck and use condition: service_healthy so a dependent waits until the dependency is actually ready.

By default depends_on only controls start order — it waits for the dependency container to start, not for the service inside it to be ready, so an app can still race ahead of a database that is still initialising. The fix is to give the dependency a healthcheck (for example pg_isready for Postgres or redis-cli ping for Redis) and then express the dependency in the long form with condition: service_healthy. The generator does this automatically: whenever a service you depend on has its healthcheck enabled, the depends_on is emitted in the long form with condition: service_healthy instead of the plain list.

A named volume (data:/path) is managed by Docker and declared under top-level volumes:; a bind mount (./src:/path) maps a host folder directly.

A named volume looks like data:/var/lib/postgresql/data — the left side is a plain name, the data is stored in a Docker-managed location, it survives docker compose down, and it must be declared in the top-level volumes: block. A bind mount looks like ./app:/app or /host/path:/path — the left side is a host path, so the container reads and writes a real folder on your machine, which is ideal for source code in development. The generator detects which is which: any mapping whose left side is a plain name is collected into the top-level volumes: block automatically, while paths starting with ., / or ~ are left as bind mounts.

Yes — it is completely free with no signup, and your services, images, ports and environment variables never leave your browser.

The Docker Compose Generator is free with no account or limits. The whole docker-compose.yml is assembled locally by a pure YAML string builder in your browser, so your service names, images, ports, environment variables and volumes stay on your device — nothing is uploaded, logged or stored — and it keeps working offline once the page has loaded. The catalog uses obvious change-me placeholders for secrets on purpose: replace them with strong passwords in an .env file before you run docker compose up, and validate first with docker compose config.

Detailed Explanation

Technical Details

A Service Catalog That Builds the services: Block for You

The Docker Compose Generator builds a valid docker-compose.yml from a friendly service builder. You add services from a catalog of 20+ common images — Nginx, Caddy and Traefik for the web tier; Node, Python, PHP and Go runtimes; Postgres, MySQL, MariaDB and MongoDB databases; Redis, RabbitMQ and Memcached for cache and queues; WordPress and Ghost for CMS; and Adminer, pgAdmin, Elasticsearch, MinIO and Mailpit as tools — each pre-filled with sensible published ports, environment variables, named volumes and, where it makes sense, a healthcheck command such as pg_isready for Postgres or redis-cli ping for Redis. Every service is fully editable: image and tag, an explicit container_name, host:container port mappings, key/value environment variables, volume mappings, the other services it depends_on, a restart policy, an optional healthcheck and an optional command that overrides the image default. You can also add a fully custom image.

  • Catalog of 20+ images grouped by web/proxy, runtime, database, cache, CMS and tools
  • Sensible defaults: ports, env vars, named volumes and a healthcheck per image
  • Per-service image+tag, container_name, ports, environment, volumes, restart, command
  • depends_on picked from the other services in the file, not free-typed
  • Add a custom image when the catalog does not cover it
Methodology

How the YAML Is Assembled: Volumes, Networks and Compose v2

A pure string builder emits correctly-indented, two-space YAML with proper quoting — values that YAML would misread as booleans, numbers or that contain structural characters are quoted so they stay strings. Service names are sanitised and de-duplicated, and depends_on references resolve to the final names. Any volume mapping whose left side is a plain name (data:/var/lib/postgresql/data) is treated as a named volume and collected into the top-level volumes: block, while paths beginning with ., / or ~ are left as bind mounts. When any service joins the shared network it is declared once in the top-level networks: block as a bridge network and each participating service lists it. The output follows the Compose Specification (Compose v2): there is no obsolete top-level version: key. When a service you depend on has its healthcheck enabled, the depends_on is upgraded from the short list form to the long form with condition: service_healthy so the dependent waits until the dependency is actually ready, not merely started.

  • Two-space indentation with context-aware quoting of scalars and env values
  • Named volumes auto-collected into top-level volumes:; bind mounts left as paths
  • Shared bridge network declared once under top-level networks:
  • No version: key — follows the modern Compose Specification (v2)
  • depends_on becomes condition: service_healthy when the target has a healthcheck
Limitations

Stack Presets, Client-Side Build and Honest Caveats

Six one-click stack presets drop in a coherent multi-service stack already wired together: WordPress + MySQL, MERN (MongoDB + Node + Nginx), Node + Postgres + Redis, LAMP (Nginx + PHP-FPM + MariaDB), Postgres + pgAdmin and Django + Postgres — each with depends_on links, a shared bridge network, matching connection-string environment variables and healthchecks on the data services. The whole docker-compose.yml is assembled by a pure YAML builder in the browser, so service names, images, ports, environment variables and volumes stay on the device — nothing is uploaded, logged or stored, and the tool works offline once cached. The output is explicit that it is a starting point, not a production-hardened deployment: the catalog seeds obvious change-me secret placeholders that must be replaced with strong, unique passwords kept in an .env file and never committed; host ports, volume paths and image versions should be adjusted to the machine (two services binding the same host port will clash); image tags should be pinned rather than left as latest for reproducibility; and the file should be validated with docker compose config before docker compose up -d.

  • Six presets: WordPress+MySQL, MERN, Node+Postgres+Redis, LAMP, Postgres+pgAdmin, Django+Postgres
  • Presets wire depends_on, a shared network and matching connection-string env
  • Built locally by a pure YAML string builder — nothing uploaded
  • Replace change-me secrets via an .env file; never commit real secrets
  • Pin tags, avoid host-port clashes, and run docker compose config before up -d
Docker Compose building: in-browser (AnyTool) vs typical online generators
CapabilityAnyToolTypical online generators
ProcessingRuns entirely in your browserOften server-side or ad-heavy
Image catalog20+ images with sensible defaultsFew or none
Stack presetsSix wired multi-service stacksRarely supported
Compose versionCompose v2 — no obsolete version: keyOften emits version: 3.x
Volumes / networksAuto-collected top-level volumes: and networks:Frequently omitted
depends_onUpgrades to condition: service_healthyPlain list only
HealthchecksPer-service, with sensible test defaultsUsually absent
OutputQuoted, indented, copy + download, live updatePlain text, manual copy
PrivacyNever uploaded, works offlineMay transmit or log input
Cost / signupFree, no signupOften gated or rate-limited

AnyTool assembles the docker-compose.yml locally in the browser and uploads nothing you type.