compose-prod

by llcsamih

Install this Skill

curl -fsSL -o compose-prod.zip https://skill.seembox.com/api/v1/skills/compose-prod/download && unzip compose-prod.zip

Download compose-prod.zip

SKILL.md About

---
name: compose-prod
description: "Generate production-grade docker-compose.yml for any project. Includes health checks for every service, network segmentation (frontend/backend/db), resource limits, log rotation, restart policies, secrets management, and backup volumes. Stack-agnostic — works with Node.js, Python, Go, Java, Ruby, PHP, or any Dockerized app. Use when the user says 'docker compose', 'production compose', 'dockerize', 'containerize', or needs a production-ready Compose file."
---

# Production Docker Compose Generator

Generate a production-grade `docker-compose.yml` from any project, with health checks, network segmentation, resource limits, logging, secrets, and backup volumes.

## When to Use

- User says "docker compose", "production compose", "dockerize", "containerize"
- User has an app and needs a production-ready Compose file
- User wants to add health checks, resource limits, or networking to an existing Compose file
- User is preparing an app for deployment with Docker

## When NOT to Use

- Kubernetes manifests (use a k8s skill)
- Cloud-managed container services (ECS, Cloud Run) with their own config formats
- Development-only Compose files where none of this matters

## Prerequisites

- A project directory with application code
- A `Dockerfile` in the project (or enough context to generate one)
- Docker and Docker Compose installed on the target machine

## Execution Flow

### Phase 1: Detect the Stack

Scan the project directory to determine:

1. **Application type** — detect from files present:
   - `package.json` -> Node.js / Next.js / Remix / etc.
   - `requirements.txt` / `pyproject.toml` / `Pipfile` -> Python
   - `go.mod` -> Go
   - `pom.xml` / `build.gradle` -> Java
   - `Gemfile` -> Ruby
   - `composer.json` -> PHP
   - `Cargo.toml` -> Rust
2. **Application port** — detect from `Dockerfile` EXPOSE, framework defaults, or ask
3. **Database dependencies** — detect from dependency files:
   - `pg`, `prisma`, `psycopg`, `sqlalchemy+postgresql` -> PostgreSQL
   - `redis`, `ioredis`, `bull`, `celery[redis]` -> Redis
   - `mongoose`, `mongodb`, `pymongo`, `motor` -> MongoDB
   - `mysql2`, `mysqlclient`, `pymysql` -> MySQL
4. **Existing Dockerfile** — check if one exists. If not, offer to generate one.
5. **Existing docker-compose.yml** — check if one exists. If upgrading, read it first.
6. **Environment variables** — scan `.env`, `.env.local`, `.env.example` for required vars

### Phase 2: Generate docker-compose.yml

Generate the full Compose file following EVERY rule below. Do NOT skip any section.

#### 2a. File Header

```yaml
# Production Docker Compose
# Generated for: <project-name>
# Stack: <detected-stack>
# Run: docker compose up -d
# Validate: docker compose config

services:
```

#### 2b. Application Service

```yaml
  app:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: <project-name>-app
    restart: unless-stopped
    ports:
      - "127.0.0.1:${APP_PORT:-3000}:${APP_PORT:-3000}"
    env_file:
      - .env
    networks:
      - frontend
      - backend
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost:${APP_PORT:-3000}/health || curl -f http://localhost:${APP_PORT:-3000}/ || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: '1.0'
        reservations:
          memory: 256M
          cpus: '0.25'
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
    depends_on:
      # Add database services here with condition: service_healthy
```

Key rules for the app service:
- **ALWAYS** bind to `127.0.0.1` — never expose directly to `0.0.0.0`. Use a reverse proxy (Nginx/Traefik/Caddy) for external traffic.
- **ALWAYS** use `env_file` instead of inline `environment` with secrets.
- **ALWAYS** include `restart: unless-stopped`.
- Adjust port, memory, and CPU based on the detected stack and expected load.
- For Next.js standalone output, set memory limit to at least 512M.
- For Python ML/AI apps, set memory limit to at least 1G.

#### 2c. Database Services

Include ONLY the databases detected in Phase 1. Every database MUST have: health check, volume, resource limits, logging, restart policy, and be on the `database` network only.

**PostgreSQL:**
```yaml
  postgres:
    image: postgres:17-alpine
    container_name: <project-name>-postgres
    restart: unless-stopped
    volumes:
      - pgdata:/var/lib/postgresql/data
      - pgbackup:/backups
    environment:
      POSTGRES_DB: ${POSTGRES_DB:-app}
      POSTGRES_USER: ${POSTGRES_USER:-app}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:?POSTGRES_PASSWORD is required}
    networks:
      - database
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER:-app} -d ${POSTGRES_DB:-app}"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: '1.0'
        reservations:
          memory: 256M
          cpus: '0.25'
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
```

**Redis:**
```yaml
  redis:
    image: redis:7-alpine
    container_name: <project-name>-redis
    restart: unless-stopped
    command: redis-server --requirepass ${REDIS_PASSWORD:-changeme} --maxmemory 256mb --maxmemory-policy allkeys-lru
    volumes:
      - redisdata:/data
    networks:
      - database
    healthcheck:
      test: ["CMD", "redis-cli", "-a", "${REDIS_PASSWORD:-changeme}", "ping"]
      interval: 10s
      timeout: 3s
      retries: 3
      start_period: 10s
    deploy:
      resources:
        limits:
          memory: 256M
          cpus: '0.5'
        reservations:
          memory: 64M
          cpus: '0.1'
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
```

**MongoDB:**
```yaml
  mongo:
    image: mongo:8
    container_name: <project-name>-mongo
    restart: unless-stopped
    volumes:
      - mongodata:/data/db
      - mongobackup:/backups
    environment:
      MONGO_INITDB_ROOT_USERNAME: ${MONGO_USER:-admin}
      MONGO_INITDB_ROOT_PASSWORD: ${MONGO_PASSWORD:?MONGO_PASSWORD is required}
      MONGO_INITDB_DATABASE: ${MONGO_DB:-app}
    networks:
      - database
    healthcheck:
      test: ["CMD", "mongosh", "--eval", "db.adminCommand('ping')", "-u", "${MONGO_USER:-admin}", "-p", "${MONGO_PASSWORD}", "--authenticationDatabase", "admin", "--quiet"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: '1.0'
        reservations:
          memory: 256M
          cpus: '0.25'
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
```

**MySQL:**
```yaml
  mysql:
    image: mysql:9
    container_name: <project-name>-mysql
    restart: unless-stopped
    volumes:
      - mysqldata:/var/lib/mysql
      - mysqlbackup:/backups
    environment:
      MYSQL_DATABASE: ${MYSQL_DB:-app}
      MYSQL_USER: ${MYSQL_USER:-app}
      MYSQL_PASSWORD: ${MYSQL_PASSWORD:?MYSQL_PASSWORD is required}
      MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD:?MYSQL_ROOT_PASSWORD is required}
    networks:
      - database
    healthcheck:
      test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "root", "-p${MYSQL_ROOT_PASSWORD}"]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 30s
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: '1.0'
        reservations:
          memory: 256M
          cpus: '0.25'
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
```

#### 2d. Network Segmentation

ALWAYS define three isolated networks. Services connect ONLY to the networks they need:

```yaml
networks:
  frontend:
    driver: bridge
    name: <project-name>-frontend
  backend:
    driver: bridge
    name: <project-name>-backend
  database:
    driver: bridge
    name: <project-name>-database
    internal: true  # No external connectivity for the database network
```

Network assignment rules:
- **frontend**: Reverse proxy (Nginx/Traefik/Caddy) and the app service
- **backend**: App service and any worker/queue services
- **database**: App service and database services ONLY
- The app service joins `frontend`, `backend`, AND `database` (it bridges all three)
- Database services join `database` ONLY — never `frontend`
- Worker services join `backend` and `database` — never `frontend`
- The `database` network MUST be `internal: true` to block external access

#### 2e. Volumes

Define named volumes for ALL persistent data. Include backup volumes for databases:

```yaml
volumes:
  pgdata:
    driver: local
    name: <project-name>-pgdata
  pgbackup:
    driver: local
    name: <project-name>-pgbackup
  redisdata:
    driver: local
    name: <project-name>-redisdata
  mongodata:
    driver: local
    name: <project-name>-mongodata
  mongobackup:
    driver: local
    name: <project-name>-mongobackup
  mysqldata:
    driver: local
    name: <project-name>-mysqldata
  mysqlbackup:
    driver: local
    name: <project-name>-mysqlbackup
```

Only include volumes for services that are actually in the Compose file.

#### 2f. Secrets (When Applicable)

For higher security, use Docker Compose file-based secrets instead of env_file for sensitive values:

```yaml
secrets:
  db_password:
    file: ./secrets/db_password.txt
  api_key:
    file: ./secrets/api_key.txt
```

Then reference in services:

```yaml
services:
  app:
    secrets:
      - db_password
      - api_key
    environment:
      DB_PASSWORD_FILE: /run/secrets/db_password
```

Secret rules:
- Default to `env_file` approach — it works everywhere and most teams know it.
- Offer the `secrets:` approach when the user asks for tighter security.
- If using secrets, create a `secrets/` directory with `.gitignore` to exclude it.
- NEVER put secrets inline in the Compose file.
- NEVER commit secret files to version control.

### Phase 3: Generate .env.example

Create a `.env.example` file listing ALL environment variables used in the Compose file with safe placeholder values:

```env
# Application
APP_PORT=3000
NODE_ENV=production

# PostgreSQL
POSTGRES_DB=app
POSTGRES_USER=app
POSTGRES_PASSWORD=CHANGE_ME_STRONG_PASSWORD

# Redis
REDIS_PASSWORD=CHANGE_ME_STRONG_PASSWORD

# MongoDB
MONGO_DB=app
MONGO_USER=admin
MONGO_PASSWORD=CHANGE_ME_STRONG_PASSWORD
```

### Phase 4: Optional Services

Offer to add these based on the project's needs. Ask the user before including:

**Nginx reverse proxy (if no external proxy exists):**
```yaml
  nginx:
    image: nginx:alpine
    container_name: <project-name>-nginx
    restart: unless-stopped
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - ./nginx/nginx.conf:/etc/nginx/nginx.conf:ro
      - ./nginx/ssl:/etc/nginx/ssl:ro
    networks:
      - frontend
    healthcheck:
      test: ["CMD-SHELL", "curl -f http://localhost/health || exit 1"]
      interval: 30s
      timeout: 10s
      retries: 3
    deploy:
      resources:
        limits:
          memory: 128M
          cpus: '0.5'
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
    depends_on:
      app:
        condition: service_healthy
```

**Worker / queue processor:**
```yaml
  worker:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: <project-name>-worker
    restart: unless-stopped
    command: <worker-command>  # e.g., "npm run worker", "celery -A app worker"
    env_file:
      - .env
    networks:
      - backend
      - database
    deploy:
      resources:
        limits:
          memory: 512M
          cpus: '1.0'
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"
    depends_on:
      app:
        condition: service_healthy
```

### Phase 5: Validate

After generating, run validation:

```bash
docker compose config
```

This checks:
- YAML syntax is valid
- All referenced env vars have defaults or are present
- Volume and network references are consistent
- No unknown keys

If validation fails, fix the issue and re-validate. Do NOT deliver an invalid Compose file.

### Phase 6: Deliver and Explain

Tell the user:

1. What services were included and why
2. Network topology — which services can talk to which
3. How to start: `docker compose up -d`
4. How to view logs: `docker compose logs -f`
5. How to check health: `docker compose ps` (shows health status)
6. How to stop: `docker compose down`
7. How to stop and delete data: `docker compose down -v` (warn: destroys volumes)
8. Remind them to copy `.env.example` to `.env` and fill in real values

## Mandatory Rules (NEVER Skip These)

1. **Health check on EVERY service** — no exceptions. If a service has no obvious health check, use `test: ["CMD-SHELL", "exit 0"]` as a placeholder and comment that the user should replace it.
2. **Resource limits on EVERY service** — memory and CPU limits prevent runaway containers.
3. **Logging with rotation on EVERY service** — `json-file` driver with `max-size: 10m` and `max-file: 3`.
4. **Restart policy on EVERY service** — `unless-stopped` for all production services.
5. **Network segmentation** — three networks minimum (frontend, backend, database). Database network MUST be `internal: true`.
6. **Named volumes** — never use bind mounts for database data in production.
7. **No exposed database ports** — databases are NEVER published to the host in the default config.
8. **env_file over inline environment** for secrets — never hardcode credentials.
9. **Backup volumes** for every database — a dedicated volume mounted at `/backups` for dump scripts.
10. **Container naming** — use `container_name: <project>-<service>` for easy identification.
11. **Port binding to 127.0.0.1** — app services bind to localhost only, not 0.0.0.0.
12. **depends_on with condition: service_healthy** — services wait for their dependencies to be healthy.
13. **Validate with `docker compose config`** before delivering.

## Adapting to Multi-Service Architectures

For microservice projects with multiple apps:

- Each service gets its own build context or image
- Shared databases are in the `database` network
- Inter-service communication happens on the `backend` network
- Only the API gateway / reverse proxy touches `frontend`
- Use `depends_on` to express the dependency graph
- Each service gets independent resource limits tuned to its role:
  - API services: 512M-1G memory
  - Workers: 256M-1G memory depending on task
  - Proxies: 128M memory
  - Databases: 512M-2G memory depending on dataset size
  - Caches (Redis): 256M memory

## Troubleshooting

- **Health check failing**: Check that the health check command is available in the container image (e.g., `curl` may not be in slim images — use `wget` or a custom binary)
- **Container OOM killed**: Increase memory limit or investigate the memory leak
- **Network connectivity issues**: Verify services are on the correct networks with `docker network inspect`
- **Secrets not readable**: Check file permissions on secret files (should be 600)
- **Compose config invalid**: Run `docker compose config` to see the expanded and validated config

_meta.json Metadata

{
  "ownerId": "kn783r2dscy71g0ery06zgh6t184frwp",
  "publishedAt": 1775627055811,
  "slug": "compose-prod",
  "version": "1.0.0"
}