Stop Docker from Killing Your Containers at Random (Exit Code 137 Is Not Your Friend)

Last month I watched a new hire spend four days trying to get our app running locally. First it was the wrong Python version. Then missing system libraries that somehow got installed on my machine six months ago. Then our frontend needed Node 18.16.1 specifically because 18.17.0 has a memory leak that breaks the build process after 20 minutes.

By day four, we were debugging why his macOS installation of libxml2 was conflicting with our parsing library. I realized we were idiots for not using containers.

VMs vs Containers: One Wastes Your RAM, One Wastes Your Sanity

Here's what I learned running both in production: VMs virtualize entire machines, so you're running a full Ubuntu installation just to serve a simple API. I've seen VMs using 2GB of RAM when the actual application needs 200MB.

Containers share the host OS kernel but isolate everything else. Same isolation, way less overhead. The downside? When the host kernel has issues, every container feels it. Learned that during a memory pressure event that killed 15 containers with OOMKilled because we hadn't set proper memory limits.

Docker Desktop Licensing: August 2021 Killed the Free Lunch

Docker Desktop Pricing Structure: Individual developers get Docker Desktop free, but companies with 250+ employees or $10M+ revenue pay $21/month per seat for Professional or $31/month for Team licensing.

In August 2021, Docker Inc. changed their licensing terms and suddenly companies with more than 250 employees had to pay $21/month per developer. Classic digital heroin dealer move: get everyone addicted, then charge for the fix. Our legal team panicked. Our DevOps team started looking at alternatives while muttering about "vendor lock-in bullshit."

We tried Podman Desktop first. It worked for basic stuff but broke our GitHub Actions because the socket path is different. Spent two weeks fixing CI scripts only to discover Podman can't handle our multi-architecture builds properly.

Rancher Desktop was next. Free, supports ARM64, but the networking stack has issues with our VPN. Some containers would randomly lose connectivity and we'd get timeout errors during builds.

What Actually Works in August 2025:

• Docker Compose v2.39+ finally has watch mode that doesn't restart containers constantly
• BuildKit 0.23+ cache invalidation actually works (learned this fixing 45-minute builds)
• Docker Desktop 4.44.3+ (released Aug 20, 2025) stopped randomly resetting memory limits to 2GB
• Docker Engine 28.0+ includes vulnerability scanning that caught 12 critical CVEs in our base images
• Dev Containers extension 0.324+ for VS Code doesn't break when you have spaces in folder names

Three Ways to Structure Your Dev Environment (Two Are Wrong)

Everything in One Container: I tried this once. Postgres, Redis, Node.js app, and nginx all in the same container. Worked great until I needed to debug a database issue and had to restart the entire stack, losing 20 minutes of work. Pure masochism.

Proper Multi-Container Setup: Separate containers for each service. Database gets its own container, cache gets its own, app server gets its own. When your app crashes (and it will), the database keeps running. When you need to update Redis, your app doesn't care. This is how we run 150+ microservices in production.

Half-Assed Hybrid: Database in Docker, everything else on the host machine. I've seen teams do this because they're scared of "complexity." You still get environment inconsistencies, plus now you have Docker AND local tooling to maintain. Pick a side.

Volume Mounts Will Destroy Your Soul (Especially on Windows)

Bind Mounts: Your source code maps directly into the container. File changes show up immediately, which sounds great until you realize Windows file I/O through Docker Desktop is slower than my first dial-up connection. Watched our CI builds go from 3 minutes on Linux to 45 minutes on Windows because of bind mount overhead.

Named Volumes: Docker manages the storage location. Lightning fast for database files, but your code changes don't appear until you rebuild. Perfect for node_modules that you never need to edit directly anyway.

The Solution That Took Me 6 Months to Figure Out: Use multi-stage Dockerfiles with a development target that includes bind mounts for source code, but named volumes for dependencies. Bind mount ./src but never ./node_modules. Your SSD will thank you.

The Reality of Docker Development (When Stars Align)

When Docker Development Actually Works: You write a Dockerfile, build an image, run containers, and use Docker Compose to orchestrate services like your database, cache, and application.

Here's how Docker development works when everything goes right:

1. New developer clones repo: git clone, docker compose up, and they're coding in 10 minutes
2. Code changes reflect immediately: Thanks to bind mounts (that work 80% of the time)
3. Database migrations just work: Same Postgres version, same data, same schema
4. Tests pass locally and in CI: Because the environment is actually identical
5. No more "missing dependency" tickets: Everything's in the container

What Actually Happens 50% of the Time:

Exit code 137 means your container got killed by the OS for using too much memory. File watching breaks when you exceed inotify limits (default is 8192 on most Linux systems). Networking randomly breaks after macOS updates because Docker Desktop has to rebuild its VM. Windows Defender will flag random Docker processes as malware because it doesn't understand containers.

• Docker Desktop randomly decides it needs 8GB of RAM for a 200MB app
• File watching stops working and you spend 2 hours debugging nodemon
• Container networking breaks after macOS update and localhost:3000 returns connection refused
• Windows Defender flags Docker Desktop as malware and quarantines the installer during updates

Tools That Actually Improved My Life:

• LazyDocker - TUI for managing containers when the GUI breaks
• Docker Scout - Found 23 vulnerabilities in our "trusted" base images
• VS Code Dev Containers - Works when you configure it correctly
• Testcontainers - Integration tests with real databases instead of mocks

After two years of using Docker for development, our team onboarding went from "3 days of environment setup" to "30 minutes of waiting for images to download." Worth the learning curve, despite the emotional trauma.

Set aside 2 hours/month for Docker maintenance - clearing old images, updating Docker Desktop, and fixing whatever randomly broke overnight. It's like owning a car: regular maintenance prevents catastrophic failures, but something will still break at the worst possible moment.

The Point of No Return: Why Docker Development Is Worth the Pain

Here's the moment you'll realize Docker was worth it: your new hire joins on Monday, runs docker compose up, and has the entire development environment working before their first meeting. No Slack messages about missing dependencies. No "it works on my machine" debugging sessions. No three-day setup process that ends with "just install this random Python library globally."

That's when you'll understand why Docker adoption went from startup toy to enterprise necessity in less than a decade. It's not about the technology - it's about solving the fundamental consistency problem that's fucked up software development since we moved beyond single-machine deployments.

Installing Docker is a pain in the ass that varies dramatically by platform. macOS forces you into Docker Desktop (which costs money now) or buggy alternatives. Windows needs WSL2 bullshit configured properly. Linux just works but you lose the pretty GUI.

Step 1: Install Docker (Platform-Specific Pain Incoming)

macOS Installation (Still Breaks Sometimes):

Downloaded Docker Desktop 4.44.3 on my M1 MacBook Pro last week. The 540MB installer took 15 minutes to download on our office WiFi. Installation was smooth until I tried to start it.

Got this error message: "Docker Desktop requires a newer version of macOS." I was running macOS 14.3, but apparently it needed 14.4+. After upgrading and restarting:

docker --version
## Docker version 28.0.2, build 445a19e
docker compose version  
## Docker Compose version v2.39.2-desktop.1

First thing I did was fix the memory allocation. Default was 2GB, which meant my laptop fan would spin up every time I ran docker compose up. Changed it to 6GB and enabled "Use Rosetta for x86/amd64 emulation" because half our dependencies don't have ARM builds yet.

Windows Installation (Three Days of My Life I'll Never Get Back):

Docker Desktop on Windows is like performing surgery with oven mitts while blindfolded. It needs WSL2 working properly, Hyper-V enabled, and enough memory allocated or your containers will crash randomly. Windows file permissions are like quantum mechanics - nobody understands them, they work differently every time you observe them, and measuring them changes the outcome.

August 2025 Update: Microsoft finally released WSL2 2.0.0 with GPU acceleration and improved file I/O, but it still takes 15 minutes to configure properly if you're unlucky enough to hit the edge cases.

Last month I helped our new junior developer set up Docker on his Windows 11 machine. Started simple:

wsl --install Ubuntu
wsl --update  
wsl --set-default-version 2

First command failed with "This operation could not be completed due to a virtual machine or Hyper-V component problem." Turns out Hyper-V was disabled in BIOS. Enabled it, restarted, tried again.

Downloaded Docker Desktop 4.44.3 (532MB). Installation succeeded but Docker wouldn't start. Error message: "WSL2 installation is incomplete." Even though wsl --list --verbose showed Ubuntu running fine.

docker run hello-world
## docker: error during connect: This error may indicate that the docker daemon is not running

Fixed it by manually enabling WSL integration in Docker Desktop settings. Three restarts later, it worked.

Windows Gotchas I Discovered:

• File permissions break when mounting Windows drives into containers
• Bind mounts are 10x slower than named volumes
• Windows PATH character limit (260) breaks complex build tools
• Windows Defender randomly decides Docker.exe is suspicious

Linux Installation (Actually Just Works):

On my Ubuntu 22.04 development server, Docker installation took 3 minutes:

## Install Docker Engine (not Desktop)
curl -fsSL https://get.docker.com -o get-docker.sh
sudo sh get-docker.sh
sudo usermod -aG docker $USER
## Logged out and back in to apply group membership

## Docker Compose comes built-in now with Docker Engine 20.10+
docker --version
## Docker version 28.0.2, build 445a19e
docker compose version
## Docker Compose version v2.39.2

Why Linux Users Are Insufferable But Completely Right About Docker:

• No licensing fees for Docker Desktop because you don't need the GUI crutch
• Native container runtime, no VM overhead because containers are a Linux thing
• File I/O at full disk speed instead of crawling through a virtualization layer like a wounded animal
• Networking just works - no bridge adapter black magic fuckery
• Cgroup controls work properly because the kernel actually knows what containers are

Builds that take 45 minutes on Windows finish in 8 minutes on Linux. Same code, same Dockerfile, massive performance difference. Windows users always ask "why is this so slow?" and Linux users just smirk knowingly.

Step 2: Create Your First Multi-Container Setup

Project Structure (Get This Right or Suffer Later):

my-app/
├── docker-compose.yml          # Service orchestration
├── docker-compose.override.yml # Development-specific settings
├── .dockerignore              # Exclude files from build context
├── backend/
│   ├── Dockerfile
│   ├── requirements.txt       # or package.json, go.mod, etc.
│   └── src/
├── frontend/
│   ├── Dockerfile
│   ├── package.json
│   └── src/
└── database/
    └── init.sql              # Database initialization

docker-compose.yml (The Heart of Your Pain):

version: '3.8'  # Don't use version '3' - it breaks stuff randomly

services:
  backend:
    build: 
      context: ./backend
      dockerfile: Dockerfile
      target: development  # Multi-stage build target
    ports:
      - "8000:8000"  # Hope this port isn't already taken
    volumes:
      - ./backend/src:/app/src:delegated  # Hot reload magic
      - backend_node_modules:/app/node_modules  # Don't bind mount this shit
    environment:
      - NODE_ENV=development
      - DATABASE_URL=postgresql://user:pass@database:5432/appdb
      - REDIS_URL=redis://redis:6379
    depends_on:
      - database
      - redis  # Startup order (doesn't guarantee readiness)

  frontend:
    build:
      context: ./frontend
      dockerfile: Dockerfile
      target: development
    ports:
      - "3000:3000"
    volumes:
      - ./frontend/src:/app/src:delegated
      - frontend_node_modules:/app/node_modules
    environment:
      - REACT_APP_API_URL=http://localhost:8000

  database:
    image: postgres:15-alpine
    ports:
      - "5432:5432"
    environment:
      - POSTGRES_DB=appdb
      - POSTGRES_USER=user
      - POSTGRES_PASSWORD=pass
    volumes:
      - postgres_data:/var/lib/postgresql/data
      - ./database/init.sql:/docker-entrypoint-initdb.d/init.sql:ro

  redis:
    image: redis:7-alpine
    ports:
      - "6379:6379"
    command: redis-server --appendonly yes
    volumes:
      - redis_data:/data

volumes:
  postgres_data:
  redis_data:
  backend_node_modules:
  frontend_node_modules:

networks:
  default:
    name: myapp-network

Create .dockerignore:

node_modules
npm-debug.log
.git
.gitignore
README.md
.env
.nyc_output
coverage
.nyc_output
.vscode
.idea

Phase 3: Make It Fast (Or At Least Not Glacially Slow)

Multi-Stage Dockerfile (Don't Copy-Paste Without Understanding):

FROM node:18-alpine AS base
WORKDIR /app
## Copy package files first (Docker layer caching)
COPY package*.json ./
## WARNING: If you don't have package-lock.json, npm will
## install different versions and your build will be fucked

## Development stage - includes dev dependencies
FROM base AS development
RUN npm ci --only=development
## Don't use npm install - it ignores your lock file like an asshole
COPY . .
EXPOSE 8000
## Make sure your dev server binds to 0.0.0.0, not localhost
CMD ["npm", "run", "dev"]

## Production stage - lean and mean
FROM base AS production
RUN npm ci --only=production && npm cache clean --force
COPY . .
EXPOSE 8000
USER node  # Don't run as root in production
CMD ["npm", "start"]

Common Dockerfile Fuckups That Will Ruin Your Day:

• Not using `.dockerignore` - your build context will be 2GB instead of 50MB because you copied your entire node_modules to the daemon
• Copying source code before installing dependencies - kills layer caching and makes every build take 10 minutes while you watch Docker reinstall the same packages for the 47th time
• Using latest tags - Docker will pull a different version than your coworker and your app breaks mysteriously at 3am on a Friday
• Running as root - security team will reject your deployment faster than you can say "privilege escalation" and make you rebuild everything as user 1001
• Not optimizing layer size - your 50MB app becomes a 1.2GB image that takes 20 minutes to pull in production
• Missing health checks - Kubernetes will think your app is healthy while it's actually crashed harder than the stock market in 2008

Hot Reload Configuration:

For development containers, configure your application to watch for file changes:

Node.js/Express:

// Use nodemon or equivalent
if (process.env.NODE_ENV === 'development') {
  // Enable hot reload
  require('nodemon')({ script: 'server.js' });
}

React/Next.js:

{
  "scripts": {
    "dev": "next dev -H 0.0.0.0",  // Bind to all interfaces
  }
}

Python/Django:

## settings.py
if DEBUG:
    # Enable auto-reload
    import os
    os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'myapp.settings')

Phase 4: Database and Service Configuration

Development vs Production Data:

Use different configurations for development and production:

## docker-compose.override.yml (automatically loaded in development)
version: '3.8'

services:
  database:
    volumes:
      - ./database/dev-seed.sql:/docker-entrypoint-initdb.d/seed.sql:ro
    environment:
      - POSTGRES_DB=appdb_dev
    
  backend:
    environment:
      - LOG_LEVEL=debug
      - DATABASE_URL=postgresql://user:pass@database:5432/appdb_dev
    command: ["npm", "run", "dev:watch"]  # Enable file watching

Production Configuration (docker-compose.prod.yml):

version: '3.8'

services:
  backend:
    build:
      target: production
    restart: unless-stopped
    environment:
      - NODE_ENV=production
      - DATABASE_URL=${DATABASE_URL}  # From environment variables
    volumes: []  # No source code volumes in production

  database:
    restart: unless-stopped
    environment:
      - POSTGRES_DB=${POSTGRES_DB}
      - POSTGRES_USER=${POSTGRES_USER} 
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD}

Phase 5: Commands That Actually Work (Most of the Time)

The Emotional Journey of Docker Development:

Sometimes it's blazing fast and you feel like a goddamn wizard. Other times you'll want to set your laptop on fire and become a farmer growing organic vegetables far from any technology. There's no middle ground with Docker - it either works perfectly or destroys your sanity in spectacular fashion.

Daily Commands for Survival:

## Start all services
docker compose up -d

## View logs from all services
docker compose logs -f

## Restart a specific service after code changes
docker compose restart backend

## Execute commands in running containers
docker compose exec backend npm test
docker compose exec database psql -U user -d appdb

## Clean restart (rebuilds containers)
docker compose down && docker compose up --build

## Stop everything and clean up
docker compose down -v  # Removes volumes too

Debugging Commands (When Shit Hits the Fan):

## Get a shell inside the broken container
docker compose exec backend sh
## Or bash if available
docker compose exec backend bash

## Check what's eating your resources
docker stats
## Spoiler: It's probably your node_modules volume

## See what Docker thinks your config looks like
docker compose config
## Useful when your YAML is fucked

## Nuclear option when nothing works
docker compose down -v && docker system prune -a
## WARNING: This nukes EVERYTHING. Hope you didn't need those containers.

## Check container processes (rarely useful but feels productive)
docker compose top

Emergency Troubleshooting:

## When Docker loses its mind (happens weekly)
docker system prune -a --volumes
## This deletes everything Docker-related

## Check Docker daemon logs (macOS/Windows)
tail -f ~/Library/Containers/com.docker.docker/Data/log/vm/dockerd.log

## Restart Docker daemon (Linux)
sudo systemctl restart docker

Phase 6: Advanced Development Features

Docker Compose Watch (2025 Feature):

## Enable automatic restarts on file changes
services:
  backend:
    develop:
      watch:
        - action: sync
          path: ./backend/src
          target: /app/src
        - action: rebuild
          path: ./backend/package.json

Health Checks for Development:

services:
  backend:
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 40s

Environment-Specific Overrides:

## Load specific environment configuration
docker compose -f docker-compose.yml -f docker-compose.test.yml up

## Run tests in isolated environment  
docker compose -f docker-compose.test.yml run --rm backend npm test

This setup gives you a production-like development environment that starts with docker compose up and supports hot reloading, debugging, and testing. Your entire team gets identical environments, eliminating "works on my machine" issues completely.

The Complete Docker Development Lifecycle: Code changes → Docker builds → Testing in containers → Production deployment with identical images. No more "it works locally but breaks in staging" nightmares.

Advanced Development Features Worth Using:

• Docker Compose profiles for optional services
• Environment variable interpolation for dynamic configuration
• Override files for environment-specific settings
• Secret management for sensitive data
• Container debugging tools for when shit hits the fan