Start from zero: what deployment actually is
Deployment is turning the code on your laptop into something that runs reliably for strangers on machines you will never touch. This is the from-zero map and the eight words the rest of the track assumes you already know.
Your app works. You typed npm run dev, opened localhost:3000, and there it is. Now a stranger on another continent needs to open it too — at 3am, while you are asleep, on a machine you have never seen and never will. Nothing on your laptop helps them: not your installed Node version, not your environment variables, not the database running in another terminal tab. Everything the rest of this track teaches exists to close that gap — between “runs on my machine” and “runs for everyone, without me.” This lesson is the map before the climb.
The one problem deployment solves
On your laptop, your program leans on a hundred invisible things: the exact language runtime you installed, libraries already downloaded, files in the right folders, secrets sitting in your shell, a database you started by hand. “It works on my machine” is true and useless — none of that context travels. Deployment is the discipline of making the program carry its own context, so it behaves identically on a bare server in a data centre as it does on your desk. Get that right and a machine can be replaced, multiplied, or moved with no surprises. Get it wrong and every server becomes a unique snowflake that only one person knows how to revive.
Everything else is detail on top of that single idea: make the run reproducible, then make it survive.
The eight words the rest of the track assumes
The senior lessons that follow drop these terms without stopping to define them. When you hit a lesson that says “the orchestrator restarts the container,” you want to already know what both words mean — otherwise two unknowns stack and the explanation loses you. Here they are, one sentence each — what it is and why it exists.
| Word | What it is | Why it exists |
|---|---|---|
| Image | A frozen snapshot of your app plus everything it needs to run. | So the same bytes run everywhere — no “install these 12 things first.” |
| Container | A running copy of an image, isolated from the rest of the machine. | So many apps share one server without stepping on each other. |
| Registry | A warehouse you push images to and servers pull them from. | So the machine that builds and the machine that runs can be different. |
| Orchestrator | Software (e.g. Kubernetes) that runs containers across many machines. | So when one machine dies, your app keeps running on the others. |
| Rollout | Replacing the running version with a new one, gradually. | So a bad deploy can be caught and undone before everyone sees it. |
| IaC (infrastructure as code) | Your servers and networks described in files, not clicked in a console. | So the setup is reviewable, repeatable, and not locked in one person’s memory. |
| Secret | A password, token, or key the app needs but must never be public. | So credentials are injected at run time, not baked into the image or git. |
| Load balancer | A front door that spreads incoming traffic across many copies. | So no single copy is overwhelmed and one dead copy is skipped. |
How they fit together
Read in order, the words tell one story: you build your code into an image, push it to a registry, and an orchestrator pulls it onto servers and starts containers from it. A rollout swaps the old containers for new ones a few at a time. A load balancer sends each user to a healthy container. Secrets are handed to the containers at start-up, and the servers themselves were created from IaC files. That single sentence is the entire track in miniature — every later unit zooms into one of those steps.
▸Why this works
Why not just copy your files onto a server with scp and run them, like the old days? Because that server slowly drifts: someone SSHes in, installs a package to fix a fire, and now it is unique. Six months later nobody can recreate it. Images and IaC exist to kill drift — the machine becomes disposable because its entire definition lives in files you can rebuild from scratch in minutes.
You do not need to memorise this
Two honest notes before the climb. First: nobody holds all of this at once on day one — you will meet each word again, in depth, in its own unit, and it will stick then. This page is a coat-hook to hang the details on, not a test. Second: not every project needs every word. A tiny side project might be one container on one machine with no orchestrator and no load balancer. The senior track teaches the full picture because that is what production at scale demands — but “start simple, add pieces when the pain shows up” is itself the senior instinct.
Why is 'it works on my machine' not enough to ship software?
Order the journey from your code to a user's request reaching it:
- 1 Build your code into an image (it now carries its own context)
- 2 Push the image to a registry
- 3 An orchestrator pulls the image onto servers and starts containers
- 4 A load balancer routes a user's request to a healthy container
- 01In one breath, what problem does deployment solve, and what is the core technique?
- 02Trace the path from your source code to a user's request reaching it, naming each piece.
Deployment is one idea with a lot of machinery hung off it: make your code carry its own context so it runs the same on a machine you do not control, then keep it running while you sleep. The reproducible half is an image — a frozen snapshot of your app and its dependencies — stored in a registry so the building machine and the running machine can differ. The survival half is everything that keeps it alive at scale: an orchestrator starts and restarts containers across many servers, a rollout swaps versions gradually so mistakes are caught early, a load balancer spreads traffic across healthy copies, secrets are injected at run time instead of baked in, and the servers themselves are defined as code so none of them is an irreplaceable snowflake. You do not need to hold all eight words at once — each gets its own unit ahead. Now when you encounter a job posting that says “experience with container orchestration required,” or a post-mortem that blames “image drift,” you will know exactly which layer broke and which word to reach for next.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.