Use when containerizing an application from scratch or generating Dockerfile and Compose configurations for a new project. Prevents insecure defaults by enforcing non-root users, multi-stage builds, health checks, and proper .dockerignore from the start. Covers Dockerfile generation for Node.js, Python, Go, Java, Rust, .NET, dev/prod Compose stacks, .dockerignore, .env templates. Keywords: Dockerfile, docker-compose.yml, multi-stage build, .dockerignore, HEALTHCHECK, non-root, FROM, COPY, ENTRYPOINT, containerize my app, dockerize, create Dockerfile for my project, how to Docker, new container setup.
Instrucciones de origen · Vista previa de solo lectura
name
docker-agents-generator
description
Use when containerizing an application from scratch or generating Dockerfile and Compose configurations for a new project. Prevents insecure defaults by enforcing non-root users, multi-stage builds, health checks, and proper .dockerignore from the start. Covers Dockerfile generation for Node.js, Python, Go, Java, Rust, .NET, dev/prod Compose stacks, .dockerignore, .env templates. Keywords: Dockerfile, docker-compose.yml, multi-stage build, .dockerignore, HEALTHCHECK, non-root, FROM, COPY, ENTRYPOINT, containerize my app, dockerize, create Dockerfile for my project, how to Docker, new container setup.
license
MIT
compatibility
Designed for Claude Code. Requires Docker Engine 24+ and Docker Compose v2.
metadata
{"author":"OpenAEC-Foundation","version":"1.0"}
docker-agents-generator
Generation Workflow
Execute these steps in order when containerizing an application:
1. Gather requirements (language, framework, database, cache)
2. Select Dockerfile template (language-specific)
3. Generate Dockerfile with multi-stage build
4. Generate .dockerignore for the language
5. Generate Compose configuration (dev and/or prod)
6. Generate .env template
7. Verify completeness
ALWAYS use -slim or -bookworm-slim variants for runtime stages
ALWAYS use the full SDK image for build stages only
NEVER ship compilers, SDKs, or build tools in production images
ALWAYS include # syntax=docker/dockerfile:1 as the first line
Step 3: Generate Dockerfile
ALWAYS follow this structure for every generated Dockerfile:
# syntax=docker/dockerfile:1
# ---- Build Stage ----
FROM <sdk-image> AS build
WORKDIR /src
# 1. Copy dependency manifests first (cache optimization)
# 2. Install dependencies with cache mounts
# 3. Copy source code
# 4. Build application
# ---- Runtime Stage ----
FROM <minimal-image> AS runtime
# 1. Create non-root user
# 2. Copy built artifacts from build stage
# 3. Set ownership and permissions
# 4. Configure health check
# 5. Switch to non-root user
# 6. Expose port
# 7. Set ENTRYPOINT and CMD
Security Defaults (ALWAYS Apply)
# Non-root user — ALWAYS include
RUN groupadd -r appuser && useradd --no-log-init -r -g appuser appuser
# Health check — ALWAYS include
HEALTHCHECK --interval=30s --timeout=3s --start-period=10s --retries=3 \
CMD <health-check-command> || exit 1
# Non-root execution — ALWAYS the last USER instruction
USER appuser
# Exec form — ALWAYS use for ENTRYPOINT
ENTRYPOINT ["/app/binary"]
target/, build/, .gradle/, *.class, *.jar (built in container)
Rust
target/, *.rs.bk
.NET
bin/, obj/, *.user, *.suo, packages/
Step 5: Generate Compose Configuration
Compose Template Decision Tree
What stack?
├─ Web + Database
│ └─ compose.yaml with app + db + named volume
├─ Web + Database + Cache
│ └─ compose.yaml with app + db + redis + named volumes
├─ Full Stack (frontend + backend + db + cache)
│ └─ compose.yaml with frontend + backend + db + redis + networks
├─ Development only
│ └─ compose.yaml with watch, bind mounts, debug ports
└─ Production only
└─ compose.yaml with resource limits, restart policy, no bind mounts
Compose Generation Rules
NEVER include the version: field (deprecated)
ALWAYS use depends_on with condition: service_healthy
ALWAYS define health checks for database and cache services
ALWAYS use named volumes for persistent data
ALWAYS use env_file instead of hardcoded environment values
ALWAYS bind ports to 127.0.0.1 in development configurations
ALWAYS include resource limits in production configurations
ALWAYS use restart: unless-stopped in production
NEVER use container_name for services that may need scaling
ALWAYS generate a .env.example file alongside Compose configurations:
# Application
APP_PORT=3000
NODE_ENV=production
# Database
POSTGRES_USER=app
POSTGRES_PASSWORD=changeme
POSTGRES_DB=appdb
# Redis (if applicable)
REDIS_PASSWORD=changeme
# Secrets — NEVER commit actual values
# Copy this file to .env and fill in real values
Rules
ALWAYS include placeholder values, NEVER real secrets
ALWAYS add a comment warning not to commit .env
ALWAYS name the template .env.example (not .env)
ALWAYS reference it from Compose via env_file: .env
Step 7: Verification Checklist
After generating all files, verify:
[ ] Dockerfile: starts with # syntax=docker/dockerfile:1
[ ] Dockerfile: uses multi-stage build (build + runtime stages)
[ ] Dockerfile: dependency manifests copied before source code
[ ] Dockerfile: uses cache mounts for package managers
[ ] Dockerfile: non-root user created and activated
[ ] Dockerfile: HEALTHCHECK instruction present
[ ] Dockerfile: ENTRYPOINT uses exec form
[ ] Dockerfile: no secrets in ENV or ARG
[ ] Dockerfile: pinned base image versions (no :latest)
[ ] .dockerignore: exists and covers language-specific patterns
[ ] Compose: no version: field
[ ] Compose: depends_on uses condition: service_healthy
[ ] Compose: all databases have healthcheck defined
[ ] Compose: named volumes for persistent data
[ ] Compose: env_file used instead of hardcoded secrets
[ ] Compose: resource limits set (production configs)
[ ] .env.example: exists with placeholder values
[ ] .env.example: no real secrets committed
