Skip to content
try reference course saved
English
Level 3: The Software World
Lesson 9 · +15 XP

Local vs deployed

You’re about to start running real code on your machine. Before you do, one last word: where code is running matters as much as what it’s running.

Code is local when it’s running on your own computer — only you can see it, and breaking it doesn’t affect anyone else. Code is deployed when it’s running on a server somewhere, accessible to other people, with real users and (usually) real data.

The same code can be both at different moments. The difference is where it lives and who can reach it.

Local — running on your laptop

When you clone a repo, install its packages, and run the dev command, the project starts running on your machine.

  • The frontend serves at something like http://localhost:3000 (from Lesson 3.4 — remember localhost).
  • The backend (if there is one) runs in a separate process, often at localhost:8000 or similar.
  • The database is usually a local copy, possibly with fake data.
  • Only your browser, on this machine, can see any of it.

This is the safe sandbox. You can break it, restart it, delete it, try ridiculous things. Nobody else is affected. Local is where most of the work happens — you’ll spend the next several levels living here.

Deployed — running somewhere real

When the code is ready to be used by actual people, it gets deployed — copied to a server on the internet, started up there, and made reachable through a real domain like acme.com.

  • The frontend is reachable at the real URL.
  • The backend runs on dedicated servers, scaled up to handle many users at once.
  • The database is the real one, with real user data. Customer accounts. Payment info. The stakes are different.
  • Anyone in the world can reach it.

You don’t deploy things lightly. Mistakes here have consequences.

The thing that trips people up

When you’re new, you’ll sometimes confuse the two and think you’re poking at your local copy when you’re actually pointed at the real, deployed thing. Or vice versa.

The single most important habit in software is knowing which environment you’re in before you do anything irreversible.

Look at the URL. Read what the terminal says when the dev server starts. Check which database your code is configured to talk to. Claude can help you verify this — and you should ask it to, especially the first dozen times.

Environments — the word teams use

Teams almost always run their software in several environments between local and deployed:

  • Local (or dev) — your laptop. Yours alone. Disposable.
  • Staging (sometimes preview or QA) — a deployed copy that looks like production but uses fake data. For testing changes before they go to real users.
  • Production (often shortened to prod) — the real one. Real users, real data. The one mistakes hurt.

A change usually travels: local → staging → production. Each step is a deploy.

When Claude (or a teammate) says “that’s a staging issue, not prod” or “don’t run that against prod,” you now have the words for what they mean.

Why this is the closer

Almost every habit the rest of this course will build comes back to this: know where your code is running. Permission prompts (Level 6), plan mode (Level 7), commits and PRs (Level 8) — they all exist to slow you down before something local accidentally becomes something deployed.

Local is the workshop. Deployed is the showroom. You don’t sand a table with customers standing on it.

What’s next

That’s the tour. You’ve got the vocabulary now — frontend, backend, client, server, URL, API, database, repo, language, framework, package, local, deployed. Every later lesson in this course assumes those words.

Level 4 is where the training wheels come off. You point Claude at a real codebase and start asking real questions about it. You’ll be glad you did this level first.