The 'works on my machine' problem

Every developer has heard it: "but it works on my machine!" Code runs fine on one computer but breaks on another — different OS, versions, dependencies, config. Docker solves this by packaging your app with everything it needs into a container that runs the same everywhere. Let's understand the problem Docker solves.

The "works on my machine" problem

# The classic scenario:
# - Your app runs perfectly on YOUR laptop.
# - You send it to a teammate -> it breaks (different OS/versions).
# - You deploy it to a server -> it breaks (missing dependencies, wrong config).

# WHY? Software depends on its ENVIRONMENT:
# - The operating system + version
# - Language runtimes (Python 3.11 vs 3.9, Node 18 vs 20)
# - Libraries + dependencies (and their exact versions)
# - System config, environment variables, tools

# If the environment differs even slightly, the app can break.
# "Works on my machine" = the app is coupled to YOUR specific environment.

The classic scenario: your app runs perfectly on YOUR laptop, but you send it to a teammate → it breaks (different OS/versions), or you deploy it to a server → it breaks (missing dependencies, wrong config). WHY? Software depends on its ENVIRONMENT: the operating system + version, language runtimes (Python 3.11 vs 3.9, Node 18 vs 20), libraries + dependencies (and their exact versions), and system config, environment variables, tools. If the environment differs even slightly, the app can break. "Works on my machine" = the app is coupled to YOUR specific environment. This is a real, common, painful problem: setting up an app's environment correctly on every machine (dev, teammate, server) is tedious and error-prone (matching versions, installing dependencies, configuring everything identically). Differences cause bugs that appear "only on some machines". The root issue: the app isn't self-contained — it relies on the environment being set up right. Docker fixes this by making the app carry its environment with it.

How Docker solves it

# Docker's solution: package the app WITH its entire environment into a
# CONTAINER.

# A container includes:
# - Your app + code
# - The runtime (Python, Node, etc.)
# - All dependencies + libraries (exact versions)
# - System tools + config it needs

# -> The container runs the SAME on any machine with Docker (your laptop,
#    a teammate's, a server, the cloud) — because it CARRIES its
#    environment with it.

# "It works on my machine" becomes "it works in the container" — and the
# container works EVERYWHERE. Consistency across all environments.

Docker's solution: package the app WITH its entire environment into a container. A container includes: your app + code, the runtime (Python, Node), all dependencies + libraries (exact versions), and system tools + config it needs. So the container runs the SAME on any machine with Docker (your laptop, a teammate's, a server, the cloud) — because it CARRIES its environment with it. "It works on my machine" becomes "it works in the container" — and the container works EVERYWHERE. Consistency across all environments. This is the core value of Docker: it packages the app + its whole environment into a portable container, eliminating environment differences. The same container runs identically everywhere (because it includes everything it needs). No more "works on my machine" — the container is the machine (a consistent, portable one). This solves the environment problem at its root: instead of setting up the environment identically on every machine, you ship the environment with the app (in the container).

Why this is transformative

# Docker containers give you:

# - CONSISTENCY: runs the same in dev, testing, and production (no
#   environment surprises).
# - PORTABILITY: runs anywhere Docker runs (any OS, any cloud).
# - ISOLATION: each container is self-contained (apps don't interfere).
# - EASY SETUP: 'docker run' instead of pages of setup instructions.
# - EFFICIENCY: lightweight (vs full virtual machines — next lesson).

# For developers: no more environment setup headaches; onboard in minutes.
# For DevOps: consistent, reliable deployments.
# For everyone: apps that "just run" anywhere.

# Docker (and containers) revolutionized how software is built, shipped,
# and run. That's why it's a fundamental modern tech skill.

Docker containers give you: CONSISTENCY (runs the same in dev, testing, and production — no environment surprises), PORTABILITY (runs anywhere Docker runs — any OS, any cloud), ISOLATION (each container is self-contained — apps don't interfere), EASY SETUP (docker run instead of pages of setup instructions), and EFFICIENCY (lightweight vs full virtual machines — next lesson). For developers: no more environment setup headaches; onboard in minutes. For DevOps: consistent, reliable deployments. For everyone: apps that "just run" anywhere. Docker (and containers) revolutionized how software is built, shipped, and run. That's why it's a fundamental modern tech skill. This is why Docker is transformative and widely used: it solves the environment problem (consistency), makes apps portable (run anywhere), simplifies setup (docker run), and enables modern deployment (containers are the unit of cloud deployment). Learning Docker is valuable — it's how modern software is packaged and shipped. This course teaches you to use it.

The mistake beginners make

Thinking "works on my machine" is unavoidable (Docker solves it — package the environment with the app). Also, underestimating the pain of environment differences (a major source of bugs and setup toil). And not understanding what a container fundamentally is (an app + its whole environment, portable). Understand the problem Docker solves: software depends on its environment (OS, versions, dependencies, config), so it breaks when the environment differs ("works on my machine"). Docker packages the app WITH its entire environment into a container that runs the SAME everywhere — solving consistency, portability, isolation, and easy setup. This revolutionized how software is built, shipped, and run — making Docker a fundamental modern skill. Containers carry their environment, so "it works in the container" everywhere. That's the problem — and the powerful solution — at the heart of Docker.

Your turn

# Reflect on the problem Docker solves:

# 1. Have you (or someone) hit "works on my machine"? (setup issues,
#    version mismatches, "it breaks on the server") — that's the problem.

# 2. The Docker solution: package the app + its WHOLE environment
#    (runtime, dependencies, config) into a CONTAINER that runs the same
#    everywhere.

# 3. Benefits: consistency, portability, isolation, easy setup, efficiency.

# In the next lessons, you'll install Docker and run your first container —
# experiencing "it just works, anywhere" firsthand.

# Docker packages the environment WITH the app -> consistency everywhere.

---

Your turn

1. Understand the 'works on my machine' problem — software depends on its environment (OS, versions, dependencies, config), so it breaks when the environment differs.
2. Understand Docker's solution — package the app WITH its entire environment into a container that runs the SAME everywhere (it carries its environment with it).
3. Know why it's transformative: consistency, portability, isolation, easy setup, and efficiency — it revolutionized how software is built, shipped, and run.

Key points

• 'Works on my machine' happens because software depends on its environment (OS, runtimes, dependency versions, config) — it breaks when the environment differs (a teammate's machine, a server).
• Docker solves it by packaging the app WITH its entire environment (runtime + dependencies + config) into a CONTAINER that runs the SAME everywhere — it carries its environment with it.
• 'It works on my machine' becomes 'it works in the container' — and the container works everywhere (consistency across dev, testing, and production).
• Benefits: consistency, portability (runs anywhere Docker runs), isolation, easy setup (docker run vs pages of instructions), and efficiency — a fundamental modern tech skill.