Post cover image

June 18, 2026

5 Docker Mistakes That Are Killing Your Laptop’s Battery

Your containers are running perfectly. Your battery is dying. These two facts are connected.

@AnandPrajapati

6 min read

You're at a coffee shop. Full charge when you sat down. Two hours of light work later — no video calls, no heavy builds — your MacBook is at 31% and the fan hasn't stopped running.

Docker is open. You didn't think about it.

This isn't bad luck. It's five specific mistakes that most developers make without realizing it, and every single one is fixable in under ten minutes.

Here's what's actually happening inside your machine — and how to stop it.

Before You Touch Anything: Measure First

Don't guess. See exactly which Docker processes are costing you:

# macOS — real-time energy impact per process
sudo powermetrics --samplers tasks -i 3000 | grep -E "Docker|hypervisor|qemu"
# Faster check — Activity Monitor → Energy tab
# Sort by "Energy Impact" — Docker will be near the top
# See exactly what's running and what it's consuming
docker stats --no-stream
# You'll see something like:
# CONTAINER    CPU %   MEM USAGE   NET I/O     BLOCK I/O
# postgres     0.8%    42MB        ...         ...
# node-app     3.2%    180MB       ...         ...
# redis        0.1%    8MB         ...         ...

That 3.2% CPU on node-app while it's "idle" is the problem. Now you know where to look.

Mistake 1: You Have Containers Running That You Forgot About

Run this right now:

docker ps

If you see anything you're not actively using, you've already found your biggest drain. Every running container — even idle ones — runs health checks on timers, writes logs to disk, and keeps processes alive in a wait loop. None of it is useful. All of it wakes your CPU every few seconds.

The permanent fix:

# Add this to your .zshrc or .bashrc — never think about it again
alias dstop='docker stop $(docker ps -q) 2>/dev/null && echo "Stopped."'
alias dclean='docker compose down && docker system prune -f'

Type dclean when you're done for the day. Everything stops. Resources fully released.

The subtler mistake inside this one:

Most developers use docker compose stop out of habit. It pauses containers but leaves them resident in memory. Use docker compose down instead — it removes the containers entirely. Unless you have a specific reason to preserve container state between sessions, down is always the right default.

docker compose stop    # containers paused, still in memory, still costing you
docker compose down    # containers gone, memory free, battery thanks you

Mistake 2: Your Health Checks Are Waking Your CPU 12 Times a Minute

This one runs silently in the background and almost nobody notices it.

Health checks are designed for production container orchestration — Kubernetes needs to know if your container is alive. On your laptop, nobody needs that information. But the default interval is 30 seconds, which means your CPU gets a wakeup call twice a minute, per container, forever.

# Default — quietly expensive on a laptop
healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
  interval: 30s     # 2 wakeups per minute per container
  timeout: 3s
  retries: 3
# Local development — correct configuration
healthcheck:
  disable: true     # you don't need orchestration health checks locally

Or if you want to keep them for parity with production:

healthcheck:
  test: ["CMD", "curl", "-f", "http://localhost:3000/health"]
  interval: 120s    # 4x fewer wakeups, negligible difference for local dev
  timeout: 10s
  start_period: 40s

The hot-reload amplifier:

Vite, Webpack dev server, Nodemon, Air (Go), and every other file watcher polls the filesystem continuously. When these run inside Docker on macOS, every filesystem event crosses the Hypervisor boundary — macOS → VM → container — which is not cheap.

Solution: run your file watcher on the host, mount the built output into the container.

# Instead of this — file watcher inside Docker on macOS
command: npm run dev   # Vite watching files inside the container
# Do this instead — Vite runs on host, container serves the output
# Terminal 1 (host): npm run dev
# Terminal 2 (host): docker compose up
volumes:
  - ./dist:/app/dist   # mount only the build output

Your laptop CPU drops noticeably. Your hot-reload is actually faster too.

Mistake 3: Your Volume Mounts Are Crossing a VM Boundary Millions of Times

This is the most technically interesting drain on macOS and the one most developers never connect to battery life.

Docker on macOS doesn't run natively. It runs inside a Linux VM managed by Apple's Hypervisor framework. Every file operation on a bind-mounted volume — every read, every write, every stat call — crosses three layers:

Your macOS filesystem
        ↓  (hypervisor boundary — expensive)
Linux VM filesystem
        ↓  (container mount — cheap)
Container process

When your Node app has node_modules on a bind mount and starts up, it reads thousands of files. Each read crosses that boundary. Each boundary crossing burns CPU. During an npm install, this is hundreds of thousands of operations.

The fix that makes the biggest difference:

# What most people have — node_modules on a bind mount
services:
  app:
    volumes:
      - .:/app    # entire project bind-mounted, including node_modules
# What you should have — node_modules in a named volume
volumes:
  node_modules:
services:
  app:
    volumes:
      - .:/app                              # source code (bind mount, necessary)
      - node_modules:/app/node_modules      # dependencies (named volume, fast)

Named volumes live entirely inside the VM. No boundary crossing. npm install inside the container drops from 45 seconds to 8 seconds on a typical project. CPU load during the operation drops by 60–70%.

Enable VirtioFS while you're at it:

Docker Desktop → Settings → General → Virtual file sharing → VirtioFS

VirtioFS is Apple's optimized file sharing implementation. It's 2–4x faster than the default gRPC FUSE implementation and uses significantly less CPU for the same I/O operations. It's been stable since Docker Desktop 4.6. There's no reason not to have it on.

Mistake 4: You're Running 900MB Production Images on a Laptop

Here's the size of common base images:

alpine:3.18          ~7MB
node:20-alpine       ~50MB
node:20-slim         ~240MB
node:20              ~1.1GB
ubuntu:22.04         ~77MB
python:3.11-slim     ~130MB
python:3.11          ~920MB

Size is a storage issue. What it represents is the battery issue.

Full images ship with package managers, debugging utilities, system daemons, logging infrastructure, and a complete OS environment. All of that initializes at startup, occupies memory, and creates background processes that run on timers. Your container is "idle" but it's actually running a small Linux distribution.

The rewrite that costs you nothing:

# What lives in your docker-compose.yml copied from production
FROM node:20
WORKDIR /app
COPY package*.json ./
RUN npm install
COPY . .
CMD ["node", "server.js"]
# Idle CPU: 2-5%, image: ~1.1GB
# What should be in your local development config
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
CMD ["node", "server.js"]
# Idle CPU: 0.1-0.4%, image: ~50MB

Same behavior. 95% smaller. Fraction of the background resource consumption.

Use separate Compose files for local vs production:

# docker-compose.yml — base config
# docker-compose.local.yml — local overrides with Alpine images
# docker-compose.prod.yml — production config
docker compose -f docker-compose.yml -f docker-compose.local.yml up

You get a clean separation. Local uses lightweight images. Production uses whatever it needs. Neither compromises the other.

Mistake 5: Docker Desktop Is Allocated Half Your CPU and You Never Changed It

Default Docker Desktop resource allocation on a modern MacBook:

CPUs:    Half your total cores  (8-core Mac → 4 cores for Docker)
Memory:  8GB
Swap:    1GB

Four dedicated CPU cores available to Docker. When containers are active — even lightly — Docker will use them. Four cores running at any meaningful load on Apple Silicon puts the CPU into a performance state, spins the fans, and generates heat. Heat means more energy. More energy means less battery.

You are not running a production Kubernetes cluster on your laptop. You do not need four dedicated CPU cores for a database and two microservices.

Open Docker Desktop → Settings → Resources → Advanced:

CPUs:    2     (sufficient for all local development workloads)
Memory:  4GB   (raise to 6GB only if you actually run out)
Swap:    512MB

This is the single change with the most immediate impact. Do this first if you do nothing else.

Two more settings worth enabling while you're there:

Settings → General:
☐ Start Docker Desktop when you log in    ← uncheck this
Settings → General:
☑ Use Rosetta for x86/amd64 emulation     ← check this (Apple Silicon)
  Rosetta is dramatically more efficient than QEMU for cross-arch containers

Docker Desktop consuming resources at login — before you've opened a single project — is pure waste. Start it when you need it.

The 5-Minute Fix: Do These Right Now

In order of impact:

# 1. Stop everything running that you don't need
docker ps
docker compose down
# 2. Add to your shell config
alias dclean='docker compose down && docker system prune -f'
# 3. Open Docker Desktop → Settings → Resources
#    CPUs: 2, Memory: 4GB
# 4. Docker Desktop → Settings → General
#    Uncheck "Start Docker Desktop when you log in"
#    Enable VirtioFS (Virtual file sharing)
# 5. In your docker-compose.yml
#    Switch base images to Alpine variants
#    Move node_modules to named volumes
#    Disable health checks

The Full Picture

Mistake Root Cause Fix Battery Impact Forgotten containers No shutdown habit dclean alias High Aggressive health checks Production config on laptop disable: true locally Medium Bind-mounted node_modules VM boundary I/O overhead Named volumes + VirtioFS High Full production images Copied from prod config Alpine variants locally Medium Default resource limits Never changed from install CPU: 2, RAM: 4GB High

None of these fixes change what your containers do. Your Postgres still runs. Your Node server still hot-reloads. Your tests still pass.

The only thing that changes is your CPU stops working overtime for work that was never necessary in the first place.

Measure before and after with powermetrics. The difference is not subtle.