# Docker (/academy/docker)



Docker is a sealed kit.

Your app does not run in a vacuum. It wants a [runtime](/academy/runtime) version, system libraries, a working directory, a few [env](/academy/env) names. Your laptop has one kit. [CI](/academy/ci-cd) has another. The [server](/academy/server) has a third. Code that behaved at 2 a.m. face-plants on the judge's machine because the desk changed, not the code.

A **container** packs the app *with* that desk. Language version, libs, settings, the command that starts it — one box. Open the box on your laptop, in CI, on a host in Virginia, and you get the same behavior, because the furniture traveled with the code.

**Docker** is the common brand of that box. "Dockerize it" means "seal this so the desk is not a coincidence." When people say container and Docker in the same breath, they mean the same kit.

**Why you care without becoming a sysadmin**

* Modern [deploys](/academy/deploy) ship the kit, not a prayer that production matches your laptop.
* An [agent](/academy/agent) can spin the project on a fresh machine and have it actually start. It brought its own desk.
* A [sandbox](/academy/sandbox) for agents is often a container with the network unplugged. Same box, smaller door.

A container is a sealed kit, not a rented building. Light enough that one machine can run many. That's the point.

You do not need Docker to win a hackathon. The [builder](/builder) and the [CLI](/academy/cli) already pick a [stack](/academy/stack) that runs with `bun install` and a URL. You need a container when the next machine is not yours — a teammate, a CI runner, a host that never heard of your global Node version — and you are tired of debugging someone else's desk.

**What this unlocks**

Until the kit is sealed, every new machine is a treasure hunt. After it is, "run this" means "open the box." Same start command. Same libs. Same result. The mystery moves out of the furniture and back into your code, which is the only mystery you wanted.