Compose vs Swarm vs Kubernetes, when do I use which?

**Compose** is for a **single host**: laptop, one VPS, one CI runner. Simplest, fastest to learn. **Swarm** is Docker's built-in clustering on top of multiple hosts, lightweight but largely on life-support. **Kubernetes** is the industry standard for **multi-node production clusters**: declarative, self-healing, auto-scaling, but a steep learning curve. Rule of thumb: one machine -> compose, a real fleet -> Kubernetes. Skip Swarm in 2026.

What is the difference between a named volume and a bind mount?

A **named [[volume||persistent storage that survives container restarts]]** (`db_data:/var/lib/postgresql/data`) is managed by Docker, lives under `/var/lib/docker/volumes/`, and survives container deletion. Best for **database data**. A **bind mount** (`./src:/app/src`) maps a folder from your host into the container. Best for **source code in dev** so changes show up live. Use volumes for state you want to persist, bind mounts for files you actively edit.

environment vs env_file, which one should I use?

Use **`environment:`** for a few values (and never put real secrets there). Use **`env_file:`** when you have many variables, want to share them across services, or load from a `.env` file you keep out of git. A common pattern: commit a `.env.example` with placeholders, write the real `.env` per environment, list it in `env_file:`, add `.env` to `.gitignore`. Compose itself **auto-reads** a `.env` next to the compose file for variable interpolation, separately from `env_file:`.

Why do I need a healthcheck?

Without a **[[healthcheck||command compose runs periodically to know if a container is actually ready]]**, "running" only means "the main process started". That is not the same as "ready to accept work". A web app may take 20 seconds to warm up. A database needs to finish initializing the data directory. A healthcheck (e.g. `pg_isready` for Postgres, `curl localhost/health` for an API) lets compose and other tools **wait for genuine readiness**. Combined with `depends_on: condition: service_healthy`, the app only starts after the database actually answers.

My app starts before the database is ready. depends_on does not work?

Correct, and this is the biggest surprise in compose. By default **[[depends_on||start order between services; does NOT wait for the dependency to be ready]]** only waits for the dependency to be **started**, not to be **ready** to accept connections. To wait for ready, add a **healthcheck** to the dependency and use `depends_on:` with `condition: service_healthy`. Without that, your app boots, tries to connect to Postgres on port 5432 in the first 200 ms, fails, and exits. Add a healthcheck or make the app retry on its own.

How do networks isolate services?

Each service joins one or more **[[networks||named virtual networks that let services talk by service name]]**. Services on the same network can reach each other by **service name** (e.g. the app connects to `db:5432`). Services on **different networks cannot see each other** unless explicitly attached to both. A common pattern: a `backend` network for app + db (private), and a `frontend` network for app + reverse proxy (public-facing). The database never gets attached to `frontend`, so the outside world cannot even route a packet to it.

ports vs expose, what is the difference?

**[[ports||host:container mapping that exposes the service to the host machine]]** (`"8080:80"`) publishes a container port on the **host machine**, reachable from your laptop and, on a server, from the internet. **[[expose||declares a port as available to other containers on the same network, NOT to the host]]** only declares the port as reachable **from other containers on the same network**, never from outside Docker. For a Postgres that only the app should reach, use `expose: ["5432"]` (or just nothing, since service-to-service uses the container port directly). Use `ports:` only for what truly needs to be public.

What restart policy should I pick?

**`no`** (the default): compose never restarts the container. Good for one-shot jobs. **`on-failure`**: restart only if it exited with a non-zero code, with optional max retries. Good for batch jobs that may flake. **`always`**: restart no matter what, including after `docker compose stop` if the Docker daemon restarts. **`unless-stopped`**: like `always`, but respects manual stops. For long-running services on a server, **`unless-stopped` is the usual pick**: it survives reboots, but if you explicitly stopped the service, it stays stopped.

Should I include the `version:` field at the top?

**No, not anymore.** The `version:` field is **obsolete in Compose v2** (built into modern Docker) and triggers a warning on every command. Compose v2 reads the schema it knows; the field is ignored. This builder omits it. Old tutorials still show `version: "3.8"` because they predate v2 (2021+), and most repos still ship it for backward compatibility, but it does nothing useful in 2026. Drop it on new files.

Docker Compose Builder - free

PresetsClick to load a sample stack

Top-level settings

Project nameBecomes the `name:` field and the prefix for container names. Leave empty to omit

Named volumesList named volumes (e.g. `db_data`), one per line. Docker creates them on `docker compose up`Extra networksNames of custom networks, one per line. By default a single `default` network is used

The `version:` field is obsolete in Compose v2 and is omitted from the output

Services2 service(s)

Basics

Service nameThe key under `services:`. Other services reach this one by name (e.g. `db:5432`)ImageFull image name with a tag, e.g. `nginx:alpine`, `postgres:16`, `redis:7-alpine`

Container name (optional)Forces an explicit container name. Leave empty in production

Format `host:container`, e.g. `8080:80`. Left side is the host port, right side is the port inside the container

Format `source:target`. Source is a named volume or a host path. The `RO` toggle marks the mount as read-only

Pairs `KEY=value`. Never commit real secrets to a file checked into git

docker-compose.yml

Paste into the file and run `docker compose up -d`

35 lines

name: wordpress

services:
  db:
    image: mysql:8.0
    volumes:
      - db_data:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: change_me
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wp
      MYSQL_PASSWORD: change_me
    restart: unless-stopped
    healthcheck:
      test: ["CMD-SHELL", "mysqladmin ping -h 127.0.0.1 -uroot -p$$MYSQL_ROOT_PASSWORD"]
      interval: 10s
      retries: 5
  wordpress:
    image: wordpress:latest
    ports:
      - "8080:80"
    volumes:
      - wp_data:/var/www/html
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DB_USER: wp
      WORDPRESS_DB_PASSWORD: change_me
    restart: unless-stopped
    depends_on:
      - db

volumes:
  db_data:
  wp_data:

Tips

The `version:` field is obsolete in Compose v2, this builder does not emit it
Save as `docker-compose.yml` in your project folder, then `docker compose up -d`
To stop and delete data: `docker compose down -v` (the -v flag removes volumes)

What docker-compose.yml is, in one paragraph

A service is one container, and a `docker-compose.yml` file is a list of services that should run together (your app, a database, maybe a cache and a reverse proxy). One command, `docker compose up`, starts the whole stack and another, `docker compose down`, takes it back to zero. It is the standard way to run multi-container apps on a single machine: dev laptops, single-node prod servers, CI runners.

This builder writes that file for you. Pick a preset (WordPress + MySQL, Node + Postgres + Redis, Nginx + PHP-FPM + MariaDB, a single Redis, a single ClickHouse), edit services in plain forms, and the right pane shows the exact YAML ready to paste into `docker-compose.yml`. Every option has a plain-language hint.

Everything runs in your browser. Nothing is uploaded, no account needed, no container actually started here - the output is the same text you would write by hand.

How to use it

Pick a preset at the top (WordPress + MySQL, Node + Postgres + Redis, Nginx + PHP-FPM + MariaDB, Single Redis, ClickHouse single-node). The form fills in sensible defaults you can tweak.

Set a project name at the top. This becomes the `name:` field in the file and the prefix for container names (no more random names like `myapp_web_1`).

For each service set: image (e.g. `nginx:alpine`), ports (host:container, repeatable), volumes (with a read-only toggle), and environment variables.

Choose a restart policy: `no`, `always`, `on-failure`, or `unless-stopped`. For production servers, `unless-stopped` is the usual pick.

Use depends_on to say "start the database before the app". Add a healthcheck on the database so other services can wait for ready, not just started.

Define networks at the top level and assign each service to one or more. Services on the same network reach each other by name (e.g. `db:5432`).

Click Copy in the preview pane, or Download to save as `docker-compose.yml`, then run `docker compose up -d` in the same folder. That is the whole flow.

When this is useful

Seven concrete situations where docker-compose makes life much easier:

A dev laptop that needs Postgres, Redis and your Node app. One file, one `docker compose up`, and your whole stack is online. No Homebrew, no apt-get, no version drift across the team.
A small VPS hosting one or two apps. Compose is the simplest path: write the file, `docker compose up -d`, set up nginx in front, done. Kubernetes is overkill for one box.
Local mirror of production. If prod runs Postgres 16, Redis 7 and Node 20, the same compose file pins those versions on every dev machine. "Works on my laptop" becomes "works on every laptop".
CI pipelines that need real services. Compose spins up a real Postgres for integration tests in seconds, then tears it down. Much closer to prod than mocks or sqlite.
Self-hosting third-party apps: WordPress, Ghost, Mastodon, NextCloud, Plausible, Gitea, n8n. The official compose file is usually the documented install path.
Bringing a stack online for a demo. You ship one repo with one file and the reviewer types one command. No "first install Postgres 14 with these extensions".
Trying out a new database. Want to play with ClickHouse, MongoDB or DuckDB without installing anything globally? `docker compose up` for five minutes, then `docker compose down -v` and the machine is clean again.

Questions and answers

A tool that runs multiple containers as a single stack, defined in one YAML file. You write what services you want (web, db, cache), how they connect, what env vars they need, which ports to expose, and `docker compose up` starts them all. `docker compose down` stops and removes everything. In modern Docker it is built in as the `docker compose` subcommand (no dash, no Python).

name: wordpress services: db: image: mysql:8.0 volumes: - db_data:/var/lib/mysql environment: MYSQL_ROOT_PASSWORD: change_me MYSQL_DATABASE: wordpress MYSQL_USER: wp MYSQL_PASSWORD: change_me restart: unless-stopped healthcheck: test: ["CMD-SHELL", "mysqladmin ping -h 127.0.0.1 -uroot -p$$MYSQL_ROOT_PASSWORD"] interval: 10s retries: 5 wordpress: image: wordpress:latest ports: - "8080:80" volumes: - wp_data:/var/www/html environment: WORDPRESS_DB_HOST: db:3306 WORDPRESS_DB_NAME: wordpress WORDPRESS_DB_USER: wp WORDPRESS_DB_PASSWORD: change_me restart: unless-stopped depends_on: - db volumes: db_data: wp_data:

What docker-compose.yml is, in one paragraph

Everything runs in your browser. Nothing is uploaded, no account needed, no container actually started here - the output is the same text you would write by hand.

How to use it

Pick a preset at the top (WordPress + MySQL, Node + Postgres + Redis, Nginx + PHP-FPM + MariaDB, Single Redis, ClickHouse single-node). The form fills in sensible defaults you can tweak.

Set a project name at the top. This becomes the `name:` field in the file and the prefix for container names (no more random names like `myapp_web_1`).

For each service set: image (e.g. `nginx:alpine`), ports (host:container, repeatable), volumes (with a read-only toggle), and environment variables.

Choose a restart policy: `no`, `always`, `on-failure`, or `unless-stopped`. For production servers, `unless-stopped` is the usual pick.

Use depends_on to say "start the database before the app". Add a healthcheck on the database so other services can wait for ready, not just started.

Define networks at the top level and assign each service to one or more. Services on the same network reach each other by name (e.g. `db:5432`).

Click Copy in the preview pane, or Download to save as `docker-compose.yml`, then run `docker compose up -d` in the same folder. That is the whole flow.

When this is useful

Seven concrete situations where docker-compose makes life much easier:

A dev laptop that needs Postgres, Redis and your Node app. One file, one `docker compose up`, and your whole stack is online. No Homebrew, no apt-get, no version drift across the team.
A small VPS hosting one or two apps. Compose is the simplest path: write the file, `docker compose up -d`, set up nginx in front, done. Kubernetes is overkill for one box.
Local mirror of production. If prod runs Postgres 16, Redis 7 and Node 20, the same compose file pins those versions on every dev machine. "Works on my laptop" becomes "works on every laptop".
CI pipelines that need real services. Compose spins up a real Postgres for integration tests in seconds, then tears it down. Much closer to prod than mocks or sqlite.
Self-hosting third-party apps: WordPress, Ghost, Mastodon, NextCloud, Plausible, Gitea, n8n. The official compose file is usually the documented install path.
Bringing a stack online for a demo. You ship one repo with one file and the reviewer types one command. No "first install Postgres 14 with these extensions".
Trying out a new database. Want to play with ClickHouse, MongoDB or DuckDB without installing anything globally? `docker compose up` for five minutes, then `docker compose down -v` and the machine is clean again.

Questions and answers

Docker Compose Builder

What docker-compose.yml is, in one paragraph

How to use it

When this is useful

Questions and answers

Related tools

Nginx Config Snippet Builder

systemd Unit Builder

iptables / nftables Builder

SSH Config Builder

Port Reachability Check

Docker Compose Builder

What docker-compose.yml is, in one paragraph

How to use it

When this is useful

Questions and answers

Related tools

Nginx Config Snippet Builder

systemd Unit Builder

iptables / nftables Builder

SSH Config Builder

Port Reachability Check