|
Docker for local development - setup, tips, and things that catch you out - Printable Version +- TalkativeTurtles (https://talkativeturtles.club) +-- Forum: Technology (https://talkativeturtles.club/forumdisplay.php?fid=2) +--- Forum: Programming & Development (https://talkativeturtles.club/forumdisplay.php?fid=9) +--- Thread: Docker for local development - setup, tips, and things that catch you out (/showthread.php?tid=74) |
Docker for local development - setup, tips, and things that catch you out - Zero Two - 06-22-2026 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? |