Docker Compose Generator

Your app needs PostgreSQL, Redis, and Nginx in front of a Node.js API. That’s four services with port mappings, volume mounts, environment variables, healthchecks, depends_on ordering, and network configuration. Writing the docker-compose.yml from scratch means remembering the exact YAML syntax for each option and hoping you didn’t get the indentation wrong — YAML is unforgiving about spaces.

Why This Generator (Not the Dockerfile Generator)

PureDevTools has a Dockerfile Generator for building single-container images. This tool is for multi-container orchestration: add services from presets (PostgreSQL, MySQL, Redis, MongoDB, Nginx, Node.js), configure ports/volumes/env/healthchecks per service, set dependencies, and get a complete docker-compose.yml. Everything runs in your browser; no data is sent anywhere.

What Is Docker Compose?

Docker Compose is a tool for defining and running multi-container Docker applications. Instead of running multiple docker run commands with dozens of flags, you describe your entire application stack in a single docker-compose.yml file:

version: "3.8"

services:
  web:
    image: nginx:latest
    ports:
      - "80:80"
    depends_on:
      - db

  db:
    image: postgres:15
    environment:
      - POSTGRES_PASSWORD=secret
    restart: unless-stopped

Then start everything with one command:

docker compose up -d

Compose handles creating networks, mounting volumes, and starting containers in the correct order.

Service Configuration Fields

image

The Docker image to run. Can be a public image from Docker Hub, a private registry image, or a locally built image.

image: nginx:latest           # Docker Hub official
image: postgres:15-alpine     # specific version + variant
image: my-registry.com/app:v1 # private registry
image: myapp:local            # locally built image

Best practice: Always pin to a specific version tag (:15, :1.25.3) rather than :latest in production. The :latest tag changes with every new release, which can break your application unexpectedly.

container_name

Override the auto-generated container name. By default Compose generates names like projectname-service-1.

container_name: my-nginx

Use this when external tools or scripts reference containers by name. Note that container names must be unique across your entire Docker host, not just within a project.

ports

Map host ports to container ports. Format: "HOST:CONTAINER".

ports:
  - "80:80"        # HTTP
  - "443:443"      # HTTPS
  - "5432:5432"    # PostgreSQL
  - "127.0.0.1:6379:6379"  # bind to localhost only

Security note: Exposing database ports (5432, 3306, 27017) on 0.0.0.0 makes them accessible from any network interface. For databases that should only be accessed by other containers, omit the ports directive and use Docker networks instead.

volumes

Mount host directories or named volumes into the container.

volumes:
  # Bind mount: host_path:container_path
  - ./html:/usr/share/nginx/html
  - ./nginx.conf:/etc/nginx/nginx.conf:ro   # :ro = read-only

  # Named volume: volume_name:container_path
  - db-data:/var/lib/postgresql/data

  # Anonymous volume: container_path only
  - /var/cache/nginx

Bind mounts (./path:/container/path) link a host directory directly into the container. Changes on the host are immediately visible inside the container, making them ideal for development.

Named volumes (volume-name:/container/path) are managed by Docker and stored in Docker’s volume storage area. They persist across container recreations and are the recommended approach for database data.

environment

Pass environment variables into the container. Use the list format KEY=VALUE or the map format.

environment:
  # List format
  - POSTGRES_DB=myapp
  - POSTGRES_USER=admin
  - POSTGRES_PASSWORD=secret

  # Map format (equivalent)
  POSTGRES_DB: myapp
  POSTGRES_USER: admin
  POSTGRES_PASSWORD: secret

  # Pass through from host environment (no value = inherit from host)
  - NODE_ENV

Security best practice: Never hardcode secrets in docker-compose.yml files committed to version control. Use Docker secrets, environment files (.env), or secret management tools for sensitive values.

depends_on

Control startup order between services.

services:
  web:
    image: myapp
    depends_on:
      - db
      - redis

  db:
    image: postgres:15

Important limitation: depends_on only waits for the container to start, not for the application inside to be ready. A PostgreSQL container starts in seconds, but the database may not be accepting connections for 10-30 more seconds. Solutions:

1. Retry logic in your application — most robust approach
2. healthcheck + condition — wait for service health before starting dependent:

depends_on:
  db:
    condition: service_healthy

db:
  image: postgres:15
  healthcheck:
    test: ["CMD", "pg_isready", "-U", "postgres"]
    interval: 5s
    timeout: 5s
    retries: 5

restart

Control automatic restart behavior.

For production services, unless-stopped is the most common choice: containers survive server reboots and Docker daemon restarts, but you can manually stop them for maintenance.

command

Override the default CMD instruction from the Docker image.

command: python manage.py runserver 0.0.0.0:8000
command: ["nginx", "-g", "daemon off;"]

Use this to pass different commands to the same image in different environments (e.g., run the web server normally but run migrations with command: python manage.py migrate).

networks

Connect the service to one or more networks. Services on the same network can reach each other by service name.

services:
  web:
    networks:
      - frontend
      - backend

  db:
    networks:
      - backend  # web can reach db, frontend clients cannot

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge

Named Volumes

Declare named volumes at the top level. Named volumes persist across docker compose down (only removed with docker compose down -v).

volumes:
  db-data:
    driver: local      # default Docker volume storage

  app-cache:
    driver: local

Reference named volumes in service definitions using volume-name:/container/path syntax. Named volumes are shared across services — multiple services can mount the same volume.

Named Networks

Custom networks isolate services and control communication paths.

networks:
  frontend:
    driver: bridge    # single host (default)

  backend:
    driver: bridge

  overlay-net:
    driver: overlay   # Docker Swarm multi-host

Bridge networks (default) are for single-host setups where containers run on the same machine.

Overlay networks span multiple Docker hosts and are used with Docker Swarm for high-availability deployments.

Common Multi-Service Patterns

Web + Database + Cache

version: "3.8"

services:
  web:
    image: myapp:latest
    ports:
      - "3000:3000"
    environment:
      - DATABASE_URL=postgres://user:pass@db:5432/mydb
      - REDIS_URL=redis://cache:6379
    depends_on:
      - db
      - cache
    restart: unless-stopped

  db:
    image: postgres:15
    environment:
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass
      - POSTGRES_DB=mydb
    volumes:
      - db-data:/var/lib/postgresql/data
    restart: unless-stopped

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

volumes:
  db-data:
    driver: local

Reverse Proxy + Application

version: "3.8"

services:
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
      - ./ssl:/etc/ssl:ro
    depends_on:
      - app
    networks:
      - frontend

  app:
    image: myapp:latest
    environment:
      - NODE_ENV=production
    networks:
      - frontend
      - backend
    restart: unless-stopped

  db:
    image: postgres:15
    volumes:
      - db-data:/var/lib/postgresql/data
    networks:
      - backend    # not accessible from nginx
    restart: unless-stopped

volumes:
  db-data:
    driver: local

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge

Service Presets

The generator includes 11 ready-made service presets to jump-start common configurations:

Each preset fills in the image, recommended port mappings, environment variables, and a healthcheck where applicable. You can modify any preset after applying it.

Healthchecks

Docker healthchecks let the daemon periodically test whether a container is healthy. Use the Healthcheck tab on any service to configure:

healthcheck:
  test: ["CMD", "pg_isready", "-U", "postgres"]
  interval: 10s
  timeout: 5s
  retries: 5
  start_period: 30s

Combine healthchecks with depends_on condition to wait for a healthy service before starting dependents:

depends_on:
  db:
    condition: service_healthy

Resource Limits

The Resources tab adds a deploy.resources block to constrain container memory and CPU:

deploy:
  resources:
    limits:
      cpus: '0.5'
      memory: 512M

Memory limit examples: 256m, 512m, 1g, 2G CPU limit examples: 0.5 (50% of one core), 1.0 (one full core), 2 (two cores)

Note: The deploy.resources syntax applies with docker stack deploy (Docker Swarm) or Docker Compose v2 CLI using the --compatibility flag. For standalone docker compose, the mem_limit and cpus keys (v2 file format) are the alternative approach.

Essential Docker Compose Commands