Letās get this out of the way first:
\nI donāt hate Docker.
\nItās brilliant for deployment.
\nContainerization is magical.
\nDockerfiles are poetry when done right.
\nBut when it comes to local development environments, I dodge Docker like itās trying to sell me an enterprise Java certification. š
\nThis is not a purist rant.
\nItās a tired developer speaking from experience.
\nSomeone whoās shipped enough code.
\nFixed enough āwhy-is-this-not-working-on-my-machineā bugs.
\nWasted enough hours debugging in container hell to make this a conscious, intentional choice.
\nYes, Docker is supposed to āabstract away the environment.ā
\nBut in practice, it often ends up replacing simple local tooling with complex orchestration.
\nInstead of running npm run dev, youāre now dealing with:
docker-compose up --buildAnd when something breaks?
\nYouāre Googling obscure Dockerfile flags or trying to mount your volumes right for the hundredth time.
\nYou become the part-time maintainer of a container orchestration mess you didnāt ask for.
\nIām all for reproducibility - but reproducibility after the dev loop, not inside it.
\nWant to read logs in real time?
\nWant to mount your code without weird permissions?
\nWant to use your IDEās debugger?
\nCool, now layer in Docker and watch all of that get clunky real fast.
\nI remember once trying to debug a Python app running in Docker, and I spent more time configuring remotePath in VSCode than actually solving the bug.
The containerized environment becomes a black box.
\nOne more place where state leaks, errors hide, and you end up wondering if the container is even picking up your code changes.
\nI donāt want to SSH into a container to fix a typo.
\nEver tried making rapid changes to code, only to wait for Docker volumes to sync or for the container to rebuild every time?
\nThat dev loop latency adds up - and so does the mental latency.
\nWhen youāre deep in flow, the last thing you want is to context-switch into Dockerās abstraction model.
\nEvery layer between you and your code makes iteration feel heavier.
\nLike trying to code in a space suit.
\nLetās not confuse dev environments with production.
\nYour dev machine is your playground.
\nIt should be flexible, hackable, and optimized for speed and feedback - not enterprise-grade reproducibility.
\nI want to brew install or apt install, maybe run a quick script, and be done.
\nIf I want to test something experimental, Iāll use a VM, a separate user profile, or even a lightweight container.
\nBut not Docker as the default dev runtime.
\nSure, it works in Docker.
\nBut if no one else on your team understands that setupā¦
\nor the image breaks silently because of a version mismatch in Alpine vs Ubuntuā¦
\nor the container dies because of an unexposed port, then what did we really solve?
\nDocker doesnāt remove config hell. It just relocates it.
\nOkay okay, itās not all fire and brimstone. Iāll use Docker in dev when:
\nBut even then, I keep my app code outside the container.
\nI let Docker handle services, not the dev runtime.
\nHereās a quick cheat sheet to sum up where Docker shines - and where it doesnāt:
\nDocker is great.
\nDocker is powerful.
\nNot every local Docker setup is a āmessā - some teams build excellent DX around Docker.
\nBut letās be honest:
\nGreat DX with Docker is rare.
\nMost of the time, itās overused in local development.
\nIf itās slowing you down, breaking your flow, or making onboarding a painā¦
\nItās okay to drop it.
\nSimpler is often better.
\nA clean dev machine is still a valid stack.
\nLet Docker shine in CI/CD, deployments, and staging.
\nNot in your everyday creative loop.
\nYouāre not wrong for wanting your tools to disappear so you can just build.
","frontmatter":{"title":"Docker Is Great, Just Not for Local Dev","date":"September 17, 2024","description":"It's great - just not in my dev loop. Here's why I avoid it for local development and what I do instead."}}},"pageContext":{"slug":"/blog/docker-is-great-just-not-for-local-dev/","previous":{"fields":{"slug":"/blog/one-wildcard-ssl-certificate-to-secure-all-subdomains-via-certbot/"},"frontmatter":{"title":"One Wildcard SSL Certificate to Secure All Subdomains via Certbot"}},"next":{"fields":{"slug":"/blog/tracking-email-for-educational-purposes/"},"frontmatter":{"title":"Tracking emails \"for educational purposes\""}}}},"staticQueryHashes":["2276319502"]}