compose-setup
The compose-setup skill generates docker-compose.yml files for applications requiring multiple services such as databases, caches, and message brokers. Use this skill when an application needs PostgreSQL, MySQL, MongoDB, Redis, RabbitMQ, or Kafka, or when deploying a monorepo with multiple independently deployable services that should run together in development or production environments.
git clone --depth 1 https://github.com/nixopus/nixopus /tmp/compose-setup && cp -r /tmp/compose-setup/api/skills/compose-setup ~/.claude/skills/compose-setupSKILL.md
# Docker Compose Setup
Generate `docker-compose.yml` when the application needs multiple services (app + database, app + cache, monorepo services).
## When to use docker-compose
- App requires a database (PostgreSQL, MySQL, MongoDB, Redis)
- App has multiple independently deployable services
- App needs a message broker (RabbitMQ, Kafka)
- Monorepo with multiple `Dockerfile` entries
Single-service apps with no external dependencies should use a standalone Dockerfile.
## Detection from source code
Look for these signals to determine required services:
| Pattern in code or config | Service needed |
|--------------------------|----------------|
| `DATABASE_URL=postgres://` or `pg` dependency | PostgreSQL |
| `DATABASE_URL=mysql://` or `mysql2` dependency | MySQL |
| `MONGODB_URI` or `mongoose` dependency | MongoDB |
| `REDIS_URL` or `ioredis`/`redis` dependency | Redis |
| `RABBITMQ_URL` or `amqplib` dependency | RabbitMQ |
| `KAFKA_BROKERS` | Kafka |
| `.env.example` listing service URLs | Parse each URL for service type |
## Compose template structure
```yaml
services:
app:
build:
context: .
dockerfile: Dockerfile
ports:
- "${PORT:-3000}:3000"
environment:
- NODE_ENV=production
- DATABASE_URL=postgresql://postgres:postgres@db:5432/app
depends_on:
db:
condition: service_healthy
restart: unless-stopped
db:
image: postgres:16-alpine
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: postgres
POSTGRES_DB: app
volumes:
- pgdata:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 5s
timeout: 3s
retries: 5
restart: unless-stopped
volumes:
pgdata:
```
## Common service blocks
### PostgreSQL
```yaml
db:
image: postgres:16-alpine
environment:
POSTGRES_USER: postgres
POSTGRES_PASSWORD: postgres
POSTGRES_DB: app
volumes:
- pgdata:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U postgres"]
interval: 5s
timeout: 3s
retries: 5
```
### MySQL
```yaml
db:
image: mysql:8.0
environment:
MYSQL_ROOT_PASSWORD: root
MYSQL_DATABASE: app
MYSQL_USER: app
MYSQL_PASSWORD: app
volumes:
- mysqldata:/var/lib/mysql
healthcheck:
test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
interval: 5s
timeout: 3s
retries: 5
```
### MongoDB
```yaml
mongo:
image: mongo:7
environment:
MONGO_INITDB_ROOT_USERNAME: root
MONGO_INITDB_ROOT_PASSWORD: root
volumes:
- mongodata:/data/db
healthcheck:
test: ["CMD", "mongosh", "--eval", "db.adminCommand('ping')"]
interval: 5s
timeout: 3s
retries: 5
```
### Redis
```yaml
redis:
image: redis:7-alpine
command: redis-server --appendonly yes
volumes:
- redisdata:/data
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 5s
timeout: 3s
retries: 5
```
## Monorepo services
For monorepos with multiple services under `apps/` or `services/`:
```yaml
services:
api:
build:
context: .
dockerfile: apps/api/Dockerfile
ports:
- "3001:3001"
depends_on:
db:
condition: service_healthy
web:
build:
context: .
dockerfile: apps/web/Dockerfile
ports:
- "3000:3000"
depends_on:
- api
```
Set build context to the repo root so shared packages are accessible. Each Dockerfile handles its own `COPY` paths.
## Rules
- Always use named volumes for persistent data
- Always add healthchecks for databases and caches
- Use `depends_on` with `condition: service_healthy` so the app waits for healthy dependencies
- Use `restart: unless-stopped` for all services
- Reference env vars from `.env.example` when available
- Default to Alpine/slim images for smaller footprint
- Pin image versions (e.g. `postgres:16-alpine`, not `postgres:latest`)
## Related Skills
- **`env-detection`** — Detect required service connection URLs (DATABASE_URL, REDIS_URL, etc.) to determine which services to include
- **`dockerfile-generation`** — Generate the Dockerfile for each service in the compose fileReference for all Nixopus API operations callable via nixopus_api(method, path, body)
Generate Caddyfile configurations for static sites and reverse proxies — SPA fallback routing, cache headers, compression, redirects, and error pages. Use when deploying a static site that needs custom Caddy configuration, or when the user needs SPA routing, caching, or redirect rules.
Size container memory and CPU limits, diagnose OOM kills and CPU throttling, and recommend resource adjustments by ecosystem. Use when containers are being OOM-killed, running slowly, or when setting initial resource limits for a deployment.
Build and deploy C/C++ applications — CMake, Meson, Ninja, and Dockerfile patterns. Use when deploying a C or C++ project, or when CMakeLists.txt or meson.build is detected.
Run database migrations safely during deployment — framework-specific commands, pre-deploy vs post-deploy timing, health gates, and rollback strategies. Use when the app has a database migration system and needs migrations run during deployment.
Build and deploy Deno applications — version detection, dependency caching, and Dockerfile patterns. Use when deploying a Deno project, or when deno.json or deno.jsonc is detected.
Sub-agent routing table — which agent handles diagnostics, machine health, infrastructure, GitHub, billing, and notifications. Load when the current task is not a direct deployment.
Full deploy pipeline — source detection, hints-driven analysis, project creation, deployment monitoring, and live URL delivery. Load when the user wants to deploy an application.