Use Docker Compose for a Repeatable Local Development Setup

A practical approach

Step 1

List the services your application needs and pin each image to a specific version that matches production.

Step 2

Define them in compose.yaml with named volumes for data and only the ports you need exposed to your machine.

Step 3

Keep local configuration in an example environment file, such as .env.example, and document how to copy it.

Step 4

Add health checks to services and, where supported, make the app wait until dependencies are healthy before starting.

Step 5

Document two commands in the README: one to start everything and one to reset local data.

Worked example

A new developer spends a day installing PostgreSQL and Redis locally, then hits a bug caused by a different PostgreSQL major version from the rest of the team. A Compose file pinning postgres:16 and redis:7, with a seed script, turns setup into one command, and everyone runs the same versions as production.

A mistake to avoid

Do not use the latest tag for services in a Compose file. Images change under you, and a teammate who pulls later may get a different major version with different behaviour.

Try it yourself

Write a compose.yaml for a project that needs a database. Pin the version, add a named volume and a health check and ask someone else to start the project from your README alone.

Your implementation checklist

• Supporting services are defined in Compose
• Image versions are pinned and match production
• Data lives in named volumes
• Local configuration is documented with an example file
• Start and reset commands are in the README