SSH Workbench

Docker Compose Generator

Build a complete docker-compose.yml file with a visual form and live YAML validation.

Client-side only — nothing leaves your browser

Services

Lowercase letters, digits, _ and -

e.g. nginx:alpine, postgres:16

Optional. Leave blank for default

HOST:CONTAINER. Add /tcp or /udp for protocol. Example: 53:53/udp

Bind mount (starts with ./ / ~) or reference a named volume defined below.

None.

Comma-separate multiple paths

Service names this one needs started first.

Names defined under the top-level networks: block.

Override the container's default command (optional)

Lowercase letters, digits, _ and -

e.g. nginx:alpine, postgres:16

Optional. Leave blank for default

HOST:CONTAINER. Add /tcp or /udp for protocol. Example: 53:53/udp

Bind mount (starts with ./ / ~) or reference a named volume defined below.

Comma-separate multiple paths

None.

Service names this one needs started first.

Names defined under the top-level networks: block.

Override the container's default command (optional)

Named volumes

Named networks

services:
  web:
    image: nginx:alpine
    restart: unless-stopped
    ports:
      - "8080:80"
    volumes:
      - ./html:/usr/share/nginx/html:ro
    depends_on:
      - db
    networks:
      - appnet

  db:
    image: postgres:16
    restart: unless-stopped
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: changeme
      POSTGRES_DB: appdb
    networks:
      - appnet

volumes:
  pgdata:

networks:
  appnet:
    driver: bridge

No issues detected

Your compose file passes structural checks. Validate further with docker compose config.

Run it

  1. 1. Save as docker-compose.yml
  2. 2. docker compose config (validate)
  3. 3. docker compose up -d (start)
  4. 4. docker compose ps (check status)

What is a docker-compose.yml File?

A docker-compose.yml file is a YAML configuration that describes a multi-container Docker application — every service (container), the named volumes that persist data between runs, the networks that connect containers, and the relationships between them. Instead of stringing together a dozen docker run flags, you declare the whole stack in one file and bring it up with docker compose up -d. This generator produces a Compose Specification file that works with both the v1 plugin (docker-compose) and the modern v2 CLI (docker compose).

Anatomy of a Compose Service

Every entry under the top-level services: key is a single container definition. These are the keys this generator emits:

KeyPurpose
imageImage tag to pull (e.g. postgres:16). Mutually exclusive with build:
container_nameFixed name instead of <project>_<service>_1. Breaks scaling — use sparingly
portsPublish container ports to the host. Format HOST:CONTAINER or HOST:CONTAINER/proto
volumesBind mounts (host paths) or named volumes for persistence
environmentInline env vars passed to the container as KEY=value
env_fileLoad env vars from one or more files. Paths are relative to the compose file
depends_onStart ordering. Does NOT wait for the dependency to be ready — only running
restartno, always, on-failure, or unless-stopped
networksWhich user-defined networks this service joins
commandOverride the image's default CMD

Docker Compose Restart Policies

The restart: key controls when the Docker daemon brings a container back up after it stops.

PolicyRestarts when
noDefault. Never restart automatically. Must be quoted in YAML or it becomes boolean false.
alwaysAlways restart, including after a host reboot — even if you stopped the container manually.
on-failureRestart only on non-zero exit. Can be limited: on-failure:5 tries five times.
unless-stoppedLike always, but respects a manual docker stop. The most common choice for long-running services.

Common docker-compose Stacks

Patterns for the most-searched Compose stacks. Use them as a starting point — paste a service into the form above and tweak.

nginx (reverse proxy / static site)

services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"
    volumes:
      - ./html:/usr/share/nginx/html:ro
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    restart: unless-stopped

PostgreSQL with persistent volume

services:
  db:
    image: postgres:16
    ports:
      - "5432:5432"
    environment:
      POSTGRES_USER: app
      POSTGRES_PASSWORD: changeme
      POSTGRES_DB: appdb
    volumes:
      - pgdata:/var/lib/postgresql/data
    restart: unless-stopped

volumes:
  pgdata:

Nextcloud + MariaDB + Redis

services:
  app:
    image: nextcloud:apache
    ports:
      - "8080:80"
    environment:
      MYSQL_HOST: db
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nextcloud
      MYSQL_PASSWORD: changeme
      REDIS_HOST: cache
    volumes:
      - nc_data:/var/www/html
    depends_on:
      - db
      - cache
    restart: unless-stopped

  db:
    image: mariadb:11
    environment:
      MYSQL_ROOT_PASSWORD: changemeroot
      MYSQL_DATABASE: nextcloud
      MYSQL_USER: nextcloud
      MYSQL_PASSWORD: changeme
    volumes:
      - db_data:/var/lib/mysql
    restart: unless-stopped

  cache:
    image: redis:alpine
    restart: unless-stopped

volumes:
  nc_data:
  db_data:

Frequently Asked Questions

What is a docker-compose.yml file?
docker-compose.yml is a YAML file that describes a multi-container Docker application. It declares every service (container) you want to run, the images they use, the ports they expose, the volumes that persist their data, the networks that connect them, and the order they start in. Once the file exists, you bring the whole stack up with 'docker compose up -d' and tear it down with 'docker compose down'. It replaces dozens of long 'docker run' commands with a single readable config you can commit to git.
Is the file docker-compose.yml or docker-compose.yaml?
Both work. The Docker Compose CLI searches the current directory in this order: compose.yaml, compose.yml, docker-compose.yaml, docker-compose.yml. The .yml and .yaml extensions are interchangeable as far as YAML and Compose are concerned — pick one and be consistent across your projects. Newer projects increasingly use the shorter 'compose.yaml' name introduced with the Compose Specification.
What is the difference between a Dockerfile and a docker-compose.yml?
A Dockerfile builds a single container image — it's a script of instructions (FROM, RUN, COPY, CMD) that the Docker daemon executes to produce an image. docker-compose.yml runs containers from images, and orchestrates multiple containers together. You typically have one Dockerfile per app, and one docker-compose.yml that references the built image (via 'build:') plus any third-party services it depends on (database, cache, reverse proxy). Build the image with 'docker build', then run the stack with 'docker compose up'.
What does depends_on do in docker-compose?
depends_on controls service start order — Compose will start the listed dependency containers before this one. Important caveat: it only waits for the dependency container to be running, not for the app inside to be ready to accept connections. A web service marked 'depends_on: [db]' will start once the Postgres container is up, but Postgres may still be initializing. For real readiness, add a healthcheck to the dependency and use the long form 'depends_on: db: condition: service_healthy', or have your app retry the connection on startup.
What restart policy should I use in docker-compose?
For most long-running production services use 'unless-stopped'. It restarts the container if it crashes, after a host reboot, and after a Docker daemon restart — but respects a manual 'docker stop', so you can take the container down for maintenance without it bouncing back. Use 'always' if you want the container to come back even after a manual stop (rare). Use 'on-failure' for jobs that should retry only on a crash, not when they exit cleanly. Leave the default 'no' for one-shot tasks. Note that 'no' must be quoted in YAML — restart: "no" — or it parses as boolean false.

Related Tools

Dockerfile Generator

Build Dockerfiles from form inputs. Multi-stage builds, healthchecks, and best-practice hints inline.

Firewall Rule Generator

Cross-platform firewall rule builder (UFW, iptables, nftables, Windows, AWS, GCP). Also explains existing rules.

iptables to nftables

Convert iptables rules to nftables. Translates chains, NAT, conntrack, and common matchers.

Nginx Config Generator

Generate nginx.conf from form inputs. Reverse proxy, SSL, static files, load balancer, and basic auth — all common modes.

Nginx to Caddy Converter

Convert nginx server blocks to Caddyfile syntax. Maps reverse_proxy, TLS, redirects, and headers.

Need to manage SSH connections?

SSH Workbench lets you connect, browse files, and manage servers visually.

Try SSH Workbench Free