PromptFork

Scaffold a multi-service local dev docker-compose stack

Produces a clean local-dev docker-compose with app, database, and cache wired via env vars, named volumes, healthchecks, and a single command to boot everything, instead of a copy-pasted snippet soup.

Open in Studio
Prompt
You are a senior platform engineer who builds local-dev environments teammates actually use.

Generate a docker-compose.yml for local development. Stack:
- App service: [LANGUAGE/FRAMEWORK — e.g. 'Node 20 + Fastify', 'Python 3.12 + FastAPI', 'Go 1.22']
- Database: [Postgres 16 / MySQL 8 / SQLite-with-no-container]
- Cache/queue: [Redis 7 / Valkey / none]
- Extra services: [e.g. 'MinIO for S3 compat', 'Mailpit', 'none']
- App run mode: [hot-reload dev server / plain run]

Produce a local-dev-first compose file with:
1. A clearly-named service per component (app, db, cache). Image tags pinned to a major version, never 'latest'.
2. Env vars read from a committed .env.example (never real secrets). The app connects to db and cache using service names and these vars.
3. Healthchecks for db and cache using the right ping command; the app depends_on them with condition: service_healthy so it boots in order.
4. Named volumes for db data and a bind mount for app source enabling hot reload. No data lost on 'down'.
5. Sensible ports exposed only on localhost (127.0.0.1:PORT), avoiding collisions with common host ports.
6. A dedicated dev network so services are isolated from other projects.

Requirements:
- No production secrets. No host Docker socket mounts. This is local dev.
- Every non-obvious line gets a short inline comment explaining why.
- It must boot with a single 'docker compose up' and tear down cleanly with 'down -v' to reset.

Output, in this exact order:
1. A .env.example with every variable the compose file reads, with placeholder values and inline notes.
2. The full docker-compose.yml with inline comments.
3. A short runbook: first-time boot, how to reset the db, how to view logs per service, a common failure and its fix.
4. A 4-item checklist of things to verify after the first successful boot.

Success signal: the output is good only if a fresh teammate can run 'docker compose up' once and reach a healthy app backed by db and cache, with no manual setup beyond copying .env.example.

Use case

Use when onboarding a new dev to a multi-service app and you want one command that brings the whole stack up correctly.

When to use this

At the start of a project or when the local dev story is breaking for teammates. Not for production deployment.

Follow-up prompts

  • Add a seed/fixture step that loads the db with sample data on first boot.
  • Add a Mailpit service and wire the app to send mail there in dev.
  • Generate a matching docker-compose.override.yml for personal dev tweaks.
#docker#docker-compose#devops#local-development#infrastructure
Source
promptfork seed
License
CC-BY-4.0
Published
6/22/2026

More prompts you might like

Harden a docker-compose file for production-grade deployment

Produces a production-grade compose with resource limits, healthchecks, restart policies, secret handling, and log rotation, clearly scoped to single-host Docker and with its limits flagged honestly.

#docker#docker-compose
New

Generate an isolated CI test stack with docker-compose

Produces a CI-runnable docker-compose test stack with ephemeral services, deterministic data, fast teardown, and exit-code propagation, so integration tests run identically locally and in CI.

#docker#docker-compose
New

Next.js 15 App Router page with streaming, caching, and server data

Scaffold a production App Router page: Server Component data fetching, Suspense streaming for instant TTFB, correct cache strategy (fetch cache vs unstable_cache vs revalidatePath), loading/error boundaries, and generateMetadata — with the non-obvious patterns most tutorials skip.

New

Tailwind analytics dashboard with animated stat cards, dark mode, and skeleton loading

Production-grade dashboard layout: KPI cards with counting animations and trend sparklines, a chart area, activity table — all with dark mode, skeleton loading states, and responsive breakpoints defined to the pixel.

New

Supabase RLS: owner-write, public-read policies for a table

Generate correct, non-recursive RLS policies so anyone reads published rows and only owners edit their own.

New

Stripe webhook handler with signature verify + idempotency

Production-ready Stripe webhook route that verifies the signature and processes events exactly once.

New