Generador Docker Compose -- Construir docker-compose.yml en Linea

1. What Is Docker Compose?

Docker Compose is a tool for defining and running multi-container Docker applications. Instead of managing individual docker run commands with lengthy flags, you describe your entire application stack in a declarative YAML file called docker-compose.yml. A single command—docker compose up—creates and starts all the services, networks, and volumes your application needs.

Compose is used everywhere: local development environments, CI/CD pipelines, staging servers, and even single-host production deployments. It bridges the gap between running one container at a time and orchestrating dozens of services with Kubernetes.

Why Use an Online Docker Compose Generator?

YAML is notoriously sensitive to indentation. A single misplaced space can break your entire stack. A Docker Compose generator provides a visual interface where you select services, configure ports, volumes, and environment variables, then export a valid, well-formatted docker-compose.yml file. Benefits include:

• Zero YAML syntax errors—the generator handles formatting automatically.
• Pre-built templates for popular services like PostgreSQL, MySQL, Redis, Nginx, and more.
• Real-time validation of port mappings, volume mounts, and network configurations.
• Quick scaffolding for new projects—go from idea to running stack in minutes.
• Learning aid—see how visual choices translate to YAML syntax.

2. Docker Compose File Structure

Every docker-compose.yml file is built around four top-level keys. Understanding this structure is essential before using any generator or writing Compose files by hand.

# docker-compose.yml — top-level structure
services:      # Define your application containers
  web:
    image: nginx:alpine
  api:
    build: ./api
  db:
    image: postgres:16

volumes:       # Declare persistent storage
  db-data:

networks:      # Define custom networks
  frontend:
  backend:

configs:       # (Optional) External configuration files
  nginx-conf:
    file: ./nginx.conf

Top-Level Keys Explained

3. Defining Services

Services are the heart of any Compose file. Each service becomes one or more running containers. Here is a complete reference of the most important service options.

Image vs Build

You can either pull a pre-built image or build from a Dockerfile:

services:
  # Pull from Docker Hub
  redis:
    image: redis:7-alpine

  # Build from local Dockerfile
  api:
    build: ./api

  # Build with advanced options
  frontend:
    build:
      context: ./frontend
      dockerfile: Dockerfile.prod
      args:
        NODE_ENV: production
        NEXT_PUBLIC_API_URL: https://api.example.com
      target: runner            # Multi-stage build target
      cache_from:
        - myapp-frontend:cache

Port Mapping

Expose container ports to the host with the ports key. The format is HOST:CONTAINER:

services:
  web:
    image: nginx:alpine
    ports:
      - "80:80"                   # HTTP
      - "443:443"                 # HTTPS
      - "127.0.0.1:8080:80"      # Bind to localhost only
      - "3000-3005:3000-3005"     # Port range

  api:
    build: ./api
    ports:
      - "3000:3000"
    expose:
      - "9229"                    # Expose to other services only (debug port)

Restart Policies

Control what happens when a container exits:

services:
  api:
    image: myapp:latest
    restart: unless-stopped

  worker:
    image: myapp:latest
    command: ["node", "worker.js"]
    restart: on-failure

4. Environment Variables

Environment variables are the primary way to configure containers. Docker Compose supports multiple approaches, each suited to different use cases.

Inline Environment

services:
  api:
    image: myapp:latest
    environment:
      NODE_ENV: production
      DB_HOST: db
      DB_PORT: "5432"
      DB_NAME: myapp
      LOG_LEVEL: info

Using env_file

services:
  api:
    image: myapp:latest
    env_file:
      - .env                    # Loaded first
      - .env.production         # Overrides values from .env

# .env file format:
# DB_HOST=localhost
# DB_PORT=5432
# DB_PASSWORD=secret123

Variable Substitution

Compose reads a .env file in the project root automatically and substitutes variables in the YAML:

# .env
POSTGRES_VERSION=16
APP_PORT=3000

# docker-compose.yml
services:
  db:
    image: postgres:${POSTGRES_VERSION}
  api:
    ports:
      - "${APP_PORT:-3000}:3000"     # Default to 3000 if not set

5. Volumes: Persistent Data

Volumes persist data beyond the lifecycle of a container. Without them, all data inside a container is lost when it stops or is recreated.

Named Volumes vs Bind Mounts

services:
  db:
    image: postgres:16
    volumes:
      # Named volume — managed by Docker, persists across restarts
      - db-data:/var/lib/postgresql/data

      # Bind mount — maps a host directory into the container
      - ./init-scripts:/docker-entrypoint-initdb.d

      # Read-only bind mount
      - ./pg-config/postgresql.conf:/etc/postgresql/postgresql.conf:ro

volumes:
  db-data:             # Declaration required for named volumes
    driver: local

6. Networks: Service Communication

By default, Docker Compose creates a single network for all services. Services can reach each other using their service name as a hostname. Custom networks let you isolate groups of services for security or clarity.

services:
  web:
    image: nginx:alpine
    networks:
      - frontend

  api:
    build: ./api
    networks:
      - frontend       # Can talk to web
      - backend        # Can talk to db

  db:
    image: postgres:16
    networks:
      - backend        # Isolated from web

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true     # No external access

7. Health Checks

Health checks let Docker monitor whether a service is actually ready to accept traffic, not just running. They are critical for reliable dependency management with depends_on.

services:
  db:
    image: postgres:16
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s       # Check every 10 seconds
      timeout: 5s         # Fail if no response in 5s
      retries: 5          # Mark unhealthy after 5 failures
      start_period: 30s   # Grace period on startup

  redis:
    image: redis:7-alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 3s
      retries: 3

  api:
    build: ./api
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:3000/health || exit 1"]
      interval: 15s
      timeout: 5s
      retries: 3
      start_period: 10s

Common Health Check Commands

8. Dependency Management with depends_on

The depends_on key controls the order in which services start. The simple list form only guarantees start order, not readiness. For true readiness, combine it with health checks.

Simple Form (Start Order Only)

services:
  api:
    build: ./api
    depends_on:
      - db
      - redis
  db:
    image: postgres:16
  redis:
    image: redis:7-alpine

Long Form with Health Conditions

services:
  api:
    build: ./api
    depends_on:
      db:
        condition: service_healthy     # Wait for DB healthcheck to pass
        restart: true                  # Restart api if db restarts
      redis:
        condition: service_healthy
      migrations:
        condition: service_completed_successfully  # Wait for one-off task

  db:
    image: postgres:16
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 5s
      retries: 10

  redis:
    image: redis:7-alpine
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      retries: 5

  migrations:
    build: ./api
    command: ["npm", "run", "migrate"]
    depends_on:
      db:
        condition: service_healthy

9. Common Docker Compose Patterns

Below are production-tested patterns you can generate with our tool or adapt for your own projects.

Pattern 1: Web + API + Database + Cache

The most common full-stack setup: a reverse proxy, an application server, a database, and a cache layer.

services:
  nginx:
    image: nginx:alpine
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
      - ./nginx/certs:/etc/nginx/certs:ro
    depends_on:
      api:
        condition: service_healthy
    restart: unless-stopped
    networks:
      - frontend

  api:
    build:
      context: ./api
      target: production
    environment:
      NODE_ENV: production
      DATABASE_URL: postgres://app:secret@db:5432/myapp
      REDIS_URL: redis://redis:6379
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:3000/health || exit 1"]
      interval: 10s
      timeout: 5s
      retries: 3
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_healthy
    restart: unless-stopped
    networks:
      - frontend
      - backend

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: myapp
      POSTGRES_USER: app
      POSTGRES_PASSWORD: secret
    volumes:
      - db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d myapp"]
      interval: 10s
      retries: 5
    restart: unless-stopped
    networks:
      - backend

  redis:
    image: redis:7-alpine
    command: redis-server --maxmemory 256mb --maxmemory-policy allkeys-lru
    volumes:
      - redis-data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      retries: 3
    restart: unless-stopped
    networks:
      - backend

volumes:
  db-data:
  redis-data:

networks:
  frontend:
  backend:
    internal: true

Pattern 2: Full-Stack JavaScript (Next.js + PostgreSQL + Redis)

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "3000:3000"
    environment:
      DATABASE_URL: postgres://dev:devpass@db:5432/nextapp
      REDIS_URL: redis://redis:6379
      NEXTAUTH_SECRET: your-secret-here
      NEXTAUTH_URL: http://localhost:3000
    volumes:
      - .:/app                   # Hot reload in development
      - /app/node_modules        # Exclude node_modules from bind mount
      - /app/.next               # Exclude .next build cache
    depends_on:
      db:
        condition: service_healthy
      redis:
        condition: service_healthy
    restart: unless-stopped

  db:
    image: postgres:16-alpine
    environment:
      POSTGRES_DB: nextapp
      POSTGRES_USER: dev
      POSTGRES_PASSWORD: devpass
    ports:
      - "5432:5432"
    volumes:
      - pgdata:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U dev"]
      interval: 5s
      retries: 10

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      retries: 5

volumes:
  pgdata:

Pattern 3: WordPress + MySQL + phpMyAdmin

services:
  wordpress:
    image: wordpress:6-apache
    ports:
      - "8080:80"
    environment:
      WORDPRESS_DB_HOST: mysql
      WORDPRESS_DB_USER: wp
      WORDPRESS_DB_PASSWORD: wppass
      WORDPRESS_DB_NAME: wordpress
    volumes:
      - wp-content:/var/www/html/wp-content
    depends_on:
      mysql:
        condition: service_healthy
    restart: unless-stopped

  mysql:
    image: mysql:8
    environment:
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wp
      MYSQL_PASSWORD: wppass
      MYSQL_ROOT_PASSWORD: rootpass
    volumes:
      - mysql-data:/var/lib/mysql
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
      interval: 10s
      retries: 5
    restart: unless-stopped

  phpmyadmin:
    image: phpmyadmin:latest
    ports:
      - "8081:80"
    environment:
      PMA_HOST: mysql
      PMA_USER: root
      PMA_PASSWORD: rootpass
    depends_on:
      mysql:
        condition: service_healthy

volumes:
  wp-content:
  mysql-data:

10. Compose File Versions: V2 vs V3

Docker Compose historically used a version field to specify the file format. Understanding the differences helps when reading older Compose files or migrating legacy projects.

11. Docker Compose Profiles

Profiles let you include optional services that only start when explicitly activated. This keeps your default docker compose up lean while allowing access to debug tools, monitoring, or testing services on demand.

services:
  api:
    build: ./api
    # No profiles = always starts

  db:
    image: postgres:16
    # No profiles = always starts

  # Only starts with --profile debug
  pgadmin:
    image: dpage/pgadmin4
    ports:
      - "5050:80"
    environment:
      PGADMIN_DEFAULT_EMAIL: admin@local.dev
      PGADMIN_DEFAULT_PASSWORD: admin
    profiles:
      - debug

  # Only starts with --profile monitoring
  prometheus:
    image: prom/prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
    profiles:
      - monitoring

  grafana:
    image: grafana/grafana
    ports:
      - "3001:3000"
    profiles:
      - monitoring

  # Only starts with --profile test
  test-runner:
    build: ./api
    command: ["npm", "test"]
    profiles:
      - test

# Start only core services
docker compose up -d

# Start core + debug tools
docker compose --profile debug up -d

# Start core + monitoring
docker compose --profile monitoring up -d

# Start everything
docker compose --profile debug --profile monitoring up -d

# Or use environment variable
COMPOSE_PROFILES=debug,monitoring docker compose up -d

12. Extending with Override Files

Docker Compose automatically merges docker-compose.yml with docker-compose.override.yml if both exist. This pattern is the standard way to separate base configuration from environment-specific overrides.

Base File (docker-compose.yml)

# docker-compose.yml — shared base config
services:
  api:
    build: ./api
    depends_on:
      db:
        condition: service_healthy
  db:
    image: postgres:16
    volumes:
      - db-data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres"]
      interval: 10s
      retries: 5
volumes:
  db-data:

Development Override (docker-compose.override.yml)

# docker-compose.override.yml — auto-merged in dev
services:
  api:
    volumes:
      - .:/app                    # Hot reload
      - /app/node_modules
    ports:
      - "3000:3000"
      - "9229:9229"              # Debug port
    environment:
      NODE_ENV: development
      LOG_LEVEL: debug
  db:
    ports:
      - "5432:5432"              # Expose DB for local tools
    environment:
      POSTGRES_PASSWORD: devpass

Production Override

# docker-compose.prod.yml — explicit -f flag needed
services:
  api:
    restart: unless-stopped
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "1.0"
    environment:
      NODE_ENV: production
      LOG_LEVEL: warn
  db:
    restart: unless-stopped
    environment:
      POSTGRES_PASSWORD_FILE: /run/secrets/db_password
    deploy:
      resources:
        limits:
          memory: 1G

# Usage:
# docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d

13. Production Best Practices

Running Docker Compose in production requires careful attention to security, reliability, and performance. Follow these guidelines for stable deployments.

Security Checklist

1. Pin image tags — Never use :latest in production. Pin to specific versions like postgres:16.2-alpine.
2. Externalize secrets — Use Docker secrets, environment files outside version control, or a secrets manager. Never commit passwords to your Compose file.
3. Run as non-root — Add user: "1000:1000" or configure your Dockerfile to drop root privileges.
4. Set read-only filesystem — Use read_only: true on services that do not need to write, and mount tmpfs for temp directories.
5. Limit network exposure — Use internal: true on backend networks. Bind ports to 127.0.0.1 unless they need external access.
6. Drop Linux capabilities — Use cap_drop: [ALL] and only add back what you need with cap_add.

Reliability Checklist

1. Set restart policies — Use restart: unless-stopped for all long-running services.
2. Add health checks — Every service should have a healthcheck so Compose and monitoring tools can detect failures.
3. Use depends_on with conditions — Ensure services start only after their dependencies are truly ready.
4. Set resource limits — Prevent any single container from consuming all host memory or CPU.
5. Configure logging — Set log drivers and rotation to prevent disk exhaustion.

Production-Ready Template

services:
  api:
    image: myapp:1.2.3                      # Pinned tag
    restart: unless-stopped
    user: "1000:1000"
    read_only: true
    tmpfs:
      - /tmp
    cap_drop:
      - ALL
    security_opt:
      - no-new-privileges:true
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "1.0"
        reservations:
          memory: 256M
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:3000/health || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 15s
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
    depends_on:
      db:
        condition: service_healthy

14. Essential Docker Compose CLI Commands

These are the commands you will use daily when working with Docker Compose:

15. Advanced Compose Features

Docker Compose Watch (Hot Reload)

Compose Watch (introduced in Docker Compose 2.22) automatically syncs file changes and rebuilds services during development:

services:
  api:
    build: ./api
    develop:
      watch:
        - action: sync
          path: ./api/src
          target: /app/src
        - action: rebuild
          path: ./api/package.json

# Usage: docker compose watch

Resource Limits

services:
  api:
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: "1.5"
        reservations:
          memory: 256M
          cpus: "0.5"

  db:
    deploy:
      resources:
        limits:
          memory: 1G
          cpus: "2.0"
      replicas: 1               # Control replica count

Logging Configuration

services:
  api:
    logging:
      driver: json-file
      options:
        max-size: "10m"         # Rotate after 10MB
        max-file: "5"           # Keep 5 rotated files
        compress: "true"

  # Alternative: send to external logging
  worker:
    logging:
      driver: syslog
      options:
        syslog-address: "tcp://logserver:514"
        tag: "myapp-worker"

Init Containers and One-Off Tasks

services:
  migrations:
    build: ./api
    command: ["npx", "prisma", "migrate", "deploy"]
    depends_on:
      db:
        condition: service_healthy
    restart: "no"               # Run once and exit

  seed:
    build: ./api
    command: ["npx", "prisma", "db", "seed"]
    depends_on:
      migrations:
        condition: service_completed_successfully
    restart: "no"

  api:
    build: ./api
    depends_on:
      seed:
        condition: service_completed_successfully

16. Troubleshooting Common Issues

Frequently Asked Questions