docker-init

Docker Init

Generate production-ready docker-compose.yml and Dockerfile with auto-detected services, health checks, resource limits, and security hardening.

Guardrails

Only generate configs based on what the codebase actually uses:

1. Scan before generating: read package.json, pyproject.toml, requirements.txt, etc. before proposing services.
2. Read existing files first: if docker-compose.yml or Dockerfile already exist, read them fully before proposing any change, and ask the user whether to update in place or regenerate. Never overwrite an existing service definition you haven't read.
3. Only well-known official images: do not invent image names or tags.
4. No secrets in files: never put secrets, passwords, or API keys in compose files, use ${VAR} references pointing at .env instead.
5. Read .dockerignore before changing it, if it exists.

Workflow

Phase 1: Scan Project

Detect the tech stack and dependencies from manifest files:

# Node.js
cat package.json 2>/dev/null | grep -E '"(pg|mysql|redis|mongodb|rabbitmq|kafka|meilisearch|elasticsearch|celery)"'

# Python
cat requirements.txt pyproject.toml 2>/dev/null | grep -iE "psycopg|pymysql|redis|pymongo|pika|kafka|celery"

# Ruby
cat Gemfile 2>/dev/null | grep -E "pg|mysql|redis|mongo|sidekiq"

# Go
cat go.mod 2>/dev/null | grep -E "postgres|mysql|redis|mongo"

# Rust
cat Cargo.toml 2>/dev/null | grep -E "postgres|mysql|redis|mongo"

Also scan:

• Source files for DATABASE_URL, REDIS_URL, MONGODB_URI, RABBITMQ_URL patterns
• Existing .env.example for service URLs
• README.md for setup instructions mentioning services

Check for existing Docker files:

ls docker-compose.yml docker-compose.yaml Dockerfile .dockerignore 2>/dev/null

Phase 2: Propose Services

Map detected dependencies to Docker services and show the proposal for the user to confirm/modify. See references/service-catalog.md for the full dependency-to-image mapping, load it whenever the scan surfaces a dependency not already covered by the examples in this file.