06-22-2026, 11:44 AM
Docker for local development has mostly won me over but it took a while to stop fighting it. Here's what I've settled on after a couple of years.
Docker Compose is the right way to do local dev
Running individual containers manually gets old fast. A docker-compose.yml that defines your app, database, and any other dependencies gives you a single docker compose up to get everything running. New team member? They clone the repo and run one command.
Dev containers vs production containers
I separate these. Production images: minimal base, no dev tools, non-root user, pinned versions. Dev images: build from the production image but add hot reload, debugger support, and don't try to be minimal. Conflating them leads to either insecure prod images or painfully slow dev workflows.
Volume mounts for code, not for everything
Mount your source code directory into the container so edits are immediately visible. But don't mount node_modules or build artifacts - they should live inside the container. The common gotcha: node_modules in a volume mount on Mac is brutally slow due to filesystem overhead.
Named volumes for databases
Data in anonymous volumes disappears on docker compose down. Named volumes persist. Use them for anything you don't want to recreate constantly.
Things that commonly trip people up:
What's your local dev Docker setup like?
Docker Compose is the right way to do local dev
Running individual containers manually gets old fast. A docker-compose.yml that defines your app, database, and any other dependencies gives you a single docker compose up to get everything running. New team member? They clone the repo and run one command.
Dev containers vs production containers
I separate these. Production images: minimal base, no dev tools, non-root user, pinned versions. Dev images: build from the production image but add hot reload, debugger support, and don't try to be minimal. Conflating them leads to either insecure prod images or painfully slow dev workflows.
Volume mounts for code, not for everything
Mount your source code directory into the container so edits are immediately visible. But don't mount node_modules or build artifacts - they should live inside the container. The common gotcha: node_modules in a volume mount on Mac is brutally slow due to filesystem overhead.
Named volumes for databases
Data in anonymous volumes disappears on docker compose down. Named volumes persist. Use them for anything you don't want to recreate constantly.
Things that commonly trip people up:
- Forgetting that localhost inside a container refers to the container, not the host. Use the service name (e.g. db) to reach other containers, or host.docker.internal on Mac/Windows to reach the host.
- Port conflicts - if something's already on 5432, your Postgres container won't bind. Use less common host ports like 5433:5432.
- .dockerignore is as important as .gitignore. Without it, your build context includes node_modules and .git and takes ages.
What's your local dev Docker setup like?