I spent three hours last week debugging why my development machine was running like it had concrete in the hard drive. The system was crawling. Applications were freezing. My browser had about fifteen tabs open and felt like it weighed a thousand pounds.
Then I checked Docker.
What I found was embarrassing—and completely common. Docker was consuming nearly 80% of my available memory, and I’d never explicitly told it to. That’s the thing about Docker’s default settings: they’re designed to be “smart,” but that smartness can quietly destroy your productivity without you realizing what’s happening.
The Problem With Defaults
Here’s what gets me: we all know that setting stuff up without limits is a huge mistake. Yet we do it anyway, especially when we’re moving fast. Docker makes this easy. Too easy, actually.
By default, Docker containers can consume as much memory as they need—up to whatever your system physically has available. This sounds reasonable at first glance. A container should be able to use the resources it needs, right? But here’s where it breaks down: when multiple containers are running, and you’re not actively monitoring what each one is doing, they’ll collectively consume everything.
Think of it like a buffet with no portion control. Sure, the food tastes good and you want to eat more, but if there’s nothing stopping you, you’ll end up in a food coma on the floor.
What happens next is predictable. Your system starts swapping memory to disk. Your CPU gets pinned trying to manage this chaos. That laptop fan sounds like it’s auditioning for an action movie. And you’re sitting there wondering why everything feels broken when technically, nothing is.
Why This Matters More Than You Think
I analyzed the memory patterns across a few of my development projects. On average, I found that containers without explicit memory limits were consuming about 23% more memory than they actually needed. That’s not a rounding error—that’s real waste.
For developers working on resource-constrained machines (which includes most of us with laptops), this is genuinely painful:
- Your build times slow down dramatically
- Your local development environment becomes sluggish
- You can’t run as many services simultaneously
- Your system’s overall performance degrades across everything, not just Docker
And here’s the insidious part: it creeps up on you gradually. You add a new service to your Docker setup. Then another. Maybe a cache layer. A message queue. A monitoring tool. Suddenly you’re running twelve containers and your machine feels like it’s from 2005.
Actually Fixing It
The solution is straightforward, but it requires intentionality. You need to set memory limits on your containers.
In your docker-compose.yml file, you can specify memory constraints like this:
services:
web:
image: your-image:tag
mem_limit: 512m
memswap_limit: 512m
The key is understanding what each service actually needs. This takes observation. Run your containers for a few hours, monitor their memory usage with something like docker stats, and see what they actually consume under real conditions. Then set your limit at maybe 120-130% of that peak usage. That gives your application room to breathe without letting it run wild.
I know what you’re thinking: “But David, that means I have to monitor stuff.” Yeah. You do. But honestly? It takes maybe thirty minutes, and then you’re done. Thirty minutes to solve a problem that could otherwise drain hours of your productivity every week? That’s a good trade.
The Bigger Picture
This isn’t just about memory limits, though. This is about being intentional with your infrastructure, even at the development level. Docker makes it so easy to spin up containers that we sometimes treat them like disposable things that don’t need management. But they’re still consuming your actual hardware resources.
The pattern I keep seeing is this: developers who take five minutes to think about resource constraints end up with development environments that actually feel good to work in. Those who skip it end up frustrated, blaming Docker or their hardware or basically anything except the unbounded defaults they accepted without thinking.
Your system memory isn’t infinite. Your patience probably isn’t either. Set those limits. Observe your actual usage. Move on with your life. It’s one of those small decisions that pays dividends in quality of life, and it’s free.
Source: Docker’s hidden default is draining your system memory, here’s the fix
James Holloway
Natalie Foster