codingDevOps

Docker Compose Development Setup

Creates a docker-compose.yml for a multi-service development environment with proper networking and volumes.

Prompt

You are a DevOps engineer specialising in containerised development environments for [industry/team type] teams. Create a docker-compose.yml for a local development setup with these services: [list services, e.g. 'Node.js API, PostgreSQL, Redis, Nginx reverse proxy']. The target audience is developers on the team, and the goal is a reliable, reproducible environment. Format the output as structured code blocks and documentation sections: (1) the docker-compose.yml file, (2) a .env.example file, (3) a Makefile with common commands. For each service provide: the official Docker image with a pinned version tag (for example, 'postgres:16.2-alpine' rather than 'latest'), port mappings, environment variables using .env file references, volume mounts for persistent data and hot-reloading, health checks, and dependency ordering with depends_on and condition: service_healthy. You must include a shared network configuration. Avoid using 'latest' tags. Only pin specific versions for reproducibility. Ensure the setup works on both macOS and Linux. Do not rely on Docker Desktop-specific features. Use Compose V2 syntax (no 'version' key). Include setup instructions as comments at the top of the file.

Why this prompt works

The 'pin specific versions, never use latest' rule is the tell that this prompt was written by someone who has actually shipped Docker setups. 'Latest' tags are how reproducible local development becomes irreproducible six months later when an image updates. The required health checks plus depends_on with condition: service_healthy is what makes the setup reliable on startup; without it, services race each other and the API tries to connect to Postgres before Postgres is ready. The Compose V2 syntax (no version key) and macOS/Linux compatibility note are also small details that distinguish a working setup from one that breaks on someone else's machine.

When to reach for it

You're spinning up local development for a new project and want a setup that doesn't require manual Docker tinkering for every team member.
You're standardising local environments across a team and want a single docker-compose.yml that works for everyone.
You're documenting an existing project for new contributors and want the local setup written down rather than tribal knowledge.
You're moving from one stack to another (e.g. adding Redis or replacing MySQL with Postgres) and want a clean reference setup.

How to customise it

The services list is the input that drives most of the output. Be specific about versions if you have constraints ('Postgres 16', 'Node.js 20 LTS'); otherwise the model picks a recent stable. For setups that need to mirror production closely, add 'use the same image versions as production'. If your team uses a specific reverse-proxy pattern (Traefik, nginx, Caddy), name it; the model's default reaches for nginx, which is fine but not always the best choice. For setups including a frontend dev server, mention hot-reload requirements explicitly so the volume mounts are configured correctly.

What good output looks like

Three artefacts: a docker-compose.yml file with pinned image versions, port mappings, env vars, volumes, health checks, and depends_on; a .env.example file with named variables and placeholder values; a Makefile with up/down/logs/shell commands. Setup instructions appear as comments at the top of the compose file. Network configuration is shared and explicit. Total length around 60 to 120 lines of YAML plus a short Makefile.

Dockerdocker-composeDevOpscontainersdevelopment environmentChatGPT / Claude