The four worlds code lives in

Mira’s change is merged into main. Between that moment and a customer’s phone, the code passes through a series of worlds. The code stays the same while the stakes rise, and this module is the journey.

First, meet the worlds.

One app, four running copies

One fact surprises most newcomers. At this moment, the coffee company is running at least four complete copies of its entire system (app, database, everything). Each copy runs on different machines, holds different data, and admits different people. Software teams call these copies environmentsConcept · lights on your mapenvironmentA separate, complete copy of the system, with its own machines, its own data, its own permitted users. Teams run several at rising levels of realism and stakes; Module 8’s configuration machinery is what points one codebase at all of them., and the standard ladder has four rungs:

Read the ladder top to bottom and two things rise together. Realism is how much each world resembles the real one, and stakes are what breaking it costs. That pairing is the entire design. Now look at each rung up close.

Development: safe to wreck

Development environmentConcept · lights on your mapdevelopment environmentWhere an engineer works: the app running on their laptop, fed invented data, breakable without consequence. Least realistic of the four copies, and the only one where crashing is free. is the engineer’s own machine, the world you already toured in Module 8. Mira runs the whole app locally against a throwaway database with a dozen fake orders in it. She can crash it forty times an hour, fill it with nonsense orders from a customer named “Test Testerson,” or delete the database entirely and recreate it in seconds.

That freedom is the point. Development is where code is wrong most of the time, by design. You saw in Module 11 that the work is a loop of try, break, fix. The loop needs a world where breaking things costs nothing.

Testing: the bots’ world

Testing environmentConcept · lights on your maptesting environmentA disposable copy the pipeline spins up to run the automated checks against, then throws away minutes later. Fresh data every run, no human residents, reborn on every push. is the world built for bots, not people. Bots is engineers’ everyday word for the automated checkers. When Mira opens her PR, servers automatically build a fresh, disposable copy of the app, run thousands of automated checks against it (next lesson’s stars) and tear the whole world down again minutes later. It exists in bursts, many times a day, born fresh every time someone pushes a change.

Its job is one question, answered by machines at machine speed: does this change break anything we already promised works?

Staging: the dress rehearsal

Staging environmentConcept · lights on your mapstaging environmentThe dress-rehearsal copy: built like production and loaded with realistic volumes of invented or anonymized data, reachable only by the team. Where scale problems and final looks happen before anything real is at risk. is a deliberate replica of production: same containers, same architecture, a database that is production-shaped (realistic in size and messiness) but fake or scrubbed, so no real customer data is at risk. It runs continuously at an address only the team can reach.

This is where humans do their final look under near-real conditions. Mira clicks through her own feature the way a customer would, the PM sees it for the first time, and problems that need scale to appear finally appear. The query that was instant against twelve fake orders reveals its true cost against two million production-shaped ones.

Staging exists because “works on my machine” (Module 8) and “works under real conditions” are separated by a canyon of realism. Staging is the bridge you inspect before driving the payload across.

Production: the real thing

And production environmentConcept · lights on your mapproduction environmentProd: the copy customers are actually using, where every order, dollar, and mistake is real. Highest realism, highest stakes, and the reason the other three copies exist., “prod” in conversation, is the world this whole curriculum has been circling: the copy serving real users, holding real data, moving real money. You’ve known the word since the terminal lesson’s “careful, I’m ssh’d into production.” Now it takes its place at the top of the ladder, where every consequence in Module 13 lives.

The cultural line is bright. In the lower three worlds, mistakes are process, but in production they are events, with customers, revenue, and sometimes headlines attached. Everything else in this module is machinery for keeping mistakes on the cheap side of that line.

How one codebase becomes four worlds

Two ideas make the ladder work, and you own both already from Module 8.

First, the same artifact climbs every rung. The container image is built once, then promoted upward unchanged, byte-identical in testing, in staging, and in production. What you rehearsed is literally what you ship.

Second, the worlds differ only by configuration. The same code reads its environment variables (which database, which keys, which settings) and connects to whatever they name. In development that is the throwaway database. In staging, the scrubbed replica. In prod, the real thing. One codebase, four worlds, and the difference between them is a handful of variables.

The ladder explains a phrase you’ll now decode instantly. “It broke in staging” is good news: the rehearsal caught it, production never saw it, no customer knows. The entire multi-million-dollar apparatus of environments exists to make sentences like that boring. The expensive sentence is the one where the same words end in “…in production.”

The mental model to remember

Environments are complete running copies of the system, arranged on a ladder where realism and stakes rise together: development (one engineer, safe to wreck), testing (bots, built and destroyed per change), staging (the team’s production replica, final rehearsal), production (everyone, real data, real money).

One artifact climbs the ladder unchanged; only configuration differs. And each world exists for one purpose: to make problems appear one rung before they would have stakes.

You should now be able to hear “does that fix work in staging?” or “is this in prod yet?” and picture exactly which world is being discussed, who is in it, and what is at risk there.