I used to Dockerize everything. Every project, every service, every side hustle — straight into a Dockerfile. It felt right. “Works on my machine” solved, reproducible environments, production parity. What could go wrong?
Turns out, a lot. At least for local development.
The Docker Desktop Tax
Docker Desktop is hungry. On my MacBook, it easily chewed through 4-6GB of RAM before I even opened a browser. Add VS Code, Chrome with 20 tabs, and a few terminal windows, and my laptop started sounding like a jet engine taking off.
I kept thinking: this is fine. Developers sacrifice comfort for consistency, right?
Wrong. I was wasting money on RAM upgrades and blaming my machine instead of my tooling choices.
The Volume Mount Problem
Most of my work involves Node.js. And here’s the thing about Docker volumes on macOS: file watching breaks. Or it’s slow. Or it works until it doesn’t.
I spent more time debugging why nodemon wasn’t picking up changes than actually writing code. The solutions exist — polling, docker-sync, Mutagen — but they’re just more things to configure and maintain.
When your local file watcher is fighting your container runtime, you’ve created a problem that didn’t need to exist.
What I Do Instead Now
For most projects, I install the runtime directly. Node? Nvm. Python? pyenv. Go? The installer. Docker Compose for the database if I need one, but the application runs native.
Here’s my typical setup:
- Local Node/Python/Go processes for the app
- Docker Compose for databases and caches (postgres, redis)
- Environment variables managed through .env files
- Init scripts to seed test data when needed
Startup time dropped from 30+ seconds to under 5. Memory usage is a fraction of what it was. File watching works perfectly.
When I Still Use Docker Locally
This isn’t a dogma. Some situations genuinely call for containerized local dev:
- Microservices with many dependencies — if your app talks to 8 other services, recreating that locally is painful
- Onboarding new developers — “run this one command” has real value when velocity matters
- Complex infrastructure — Kafka, Elasticsearch, and friends aren’t fun to install natively
But for CRUD apps, APIs, and typical web projects? Native development is faster and closer to how you’ll actually debug issues.
The Real Lesson
Technology should serve you, not the other way around. I adopted Docker everywhere because it was the popular thing, not because it made sense for every context.
Now I ask one question before containerizing: “What’s the actual cost of running this locally?” If it’s just an installation step and maybe a config file, skip the Dockerfile.
Save Docker for where it actually earns its overhead — production deployments, CI pipelines, and complex multi-service architectures.