Docker

Docker is a sealed kit.

Your app does not run in a vacuum. It wants a runtime version, system libraries, a working directory, a few env names. Your laptop has one kit. CI has another. The 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 ship the kit, not a prayer that production matches your laptop.
• An agent can spin the project on a fresh machine and have it actually start. It brought its own desk.
• A 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 and the CLI already pick a 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.