In Part VI you built something worth keeping: a database that remembers facts, sources, and results even after you close your laptop. But try this experiment. Close the laptop. Does your product still answer a visitor's question? No — because remembering is not the same as running.

Infrastructure is what keeps the product awake after you walk away.

The laptop-closes test

Everything so far has lived mostly on your machine. You wrote code in an editor, ran it in a terminal, queried a local or hosted database, called a model API. It worked — while you were watching.

Now picture a stranger at midnight opening your ByeBuy research product and asking, "What did this company file last quarter, with sources?" Your laptop is shut in a bag. Your terminal is dead. Nothing on your machine can answer.

"Live" means something very concrete: some other machine, somewhere else, is awake and ready to receive that request. That machine, plus the network path to it, the settings it carries, and the logs it writes, is infrastructure.

Here is the course definition to carry forward:

Infrastructure is the computers, network services, storage, and settings that keep an application available.

First, the word the whole part depends on: process

Before we go further, fix one word, because the rest of Part VII uses it constantly:

A process is a program currently executing — not code saved in a folder.

Saved code sits still. A process breathes. When you run python app.py and the terminal waits, that running instance is a process. A web server listening for requests is a process. An API handler, a background worker, a Discord-style bot sitting in a channel — each is a process only while something is actually running it.

Kill the power, close the laptop lid, stop the command — the process ends. The files remain, but nothing answers. This is why "I wrote the code" is never the same claim as "the product is live." Live means at least one process is running somewhere right now, ready to do the job.

The smallest live-product path

A live product is a chain, and every link must be awake and reachable:

visitor → domain → running application (process)
  → database / API / model → response back to visitor

Walk it with a real request:

1. A visitor types your product's address or clicks a link. 2. The domain routes that human-friendly name toward your running service. 3. Your running application — a live process — receives the request. 4. That process reads its database, calls an outside API or a model if needed. 5. It assembles a response and sends it back.

If any link sleeps, the chain breaks. The domain can point correctly, but with no running process there is nothing to answer. The database can hold perfect data, but with no process asking, nobody reads it. The model can be brilliant, but with no process calling, it never hears the question.

Draw this on paper once. It will return in every lesson of this part: functions, workers, queues, cron, webhooks — all of them are answers to "which piece of this path wakes up, when, and where?"

Code vs. data vs. infrastructure

Beginners blur three things that fail in completely different ways. Separate them now:

Code is a recipe. Data is the pantry. Infrastructure is the kitchen that stays open — with power, staff, and a door customers can find.

A ByeBuy walkthrough: the question that needs all three

Imagine a small public data-research product, the kind this course builds toward. A visitor asks: "Summarize Acme Corp's latest 10-K risk section, with citations."

Here is what must happen while your laptop is closed:

1. The visitor's browser reaches your domain, which routes to your running web process. 2. That process checks its environment settings — secret credentials for the database and the model provider, loaded from safe configuration, never pasted into code. 3. It queries its database for approved source data: the filing's identity, its source URL, previously extracted text. 4. If a fresh summary is needed, it calls the model API with the retrieved facts and citation rules. 5. It returns a cited answer and writes a log line: who asked, what was read, how long it took, whether it succeeded.

Each piece must be reachable *and* credentialed. The process needs permission to read the database. It needs a key for the model. The visitor needs a network path to the process. None of that happens because the code exists. It happens because infrastructure holds the process up, feeds it secrets, connects it to data, and records what it did.

That is the bridge from Part VI. Data gave you something worth serving. Infrastructure gives it a dependable place to run.

The six operating questions

Every product in this part — whether it ends up on a VPS, a managed platform, or a serverless function — must answer the same six questions:

1. Where does it run? Which machine or platform holds the process? 2. What starts it? A deploy, a reboot, a schedule, a visitor's request? 3. What wakes it back up after failure? Restart policy, health check, a human with a runbook? 4. How does it get secrets? Environment settings on the host — not secrets committed to the repository. 5. Where do logs go? A place you can read after something breaks at 2 a.m. 6. What can it cost? Compute, storage, bandwidth, and model calls — with an alert before surprise.

You do not need the answers today. You need the list. Lessons 24.2 through 27.4 are a systematic tour of those answers. A VPS, which you meet next lesson, is *one* answer to question one — not the only answer.

Visual: asleep on the left, awake on the right

Picture a two-panel diagram:

• Left: laptop-only project. Laptop lid closing, terminal process dying, an arrow to the product that now reads "nobody home." Label it: code saved, process gone.
• Right: live product. A running process box in the middle, with four connections: domain on the left bringing visitors in, database below feeding facts, model API above answering calls, and a log stream flowing out to the right. Label each arrow in large text.

The teaching point sits underneath: *the code is identical in both panels. Only the right panel has infrastructure keeping a process awake.*

Practical exercise: map your product's awake-state

Create a file called INFRASTRUCTURE-NOTES.md for one project — real or planned. Write five short answers, one or two sentences each:

1. User entry point: How does a stranger reach it? (Domain? URL? Bot channel?) 2. Running code: Which process must be awake to answer? (Web app? API? Bot?) 3. Data home: Where do the facts live? (Which database or store?) 4. Outside services: What else gets called? (Model provider? Source APIs?) 5. Must-work-while-closed: What specifically must keep working after your laptop shuts?

Finish line: a one-page map that separates code, data, and the place the code runs — readable by someone who has never seen your project.

Verify: hand it to a friend (or a fresh AI session) and ask: "Point to the process, the data, and the place." If they cannot, the map is not done.

Common failure mode: listing tools ("Python, Postgres, OpenAI") instead of the running picture ("a web process on ___ reads ___ and calls ___"). Tools are ingredients. This map is the kitchen schedule.

Check your understanding

1. In plain language, what is infrastructure — and what is a process? 2. Why does closing your laptop take a laptop-run product offline, even though the code and data still exist? 3. Name the five links in the smallest live-product path, in order. 4. What is the difference between application code, data, and infrastructure? Give one failure unique to each. 5. In the research-product walkthrough, why does the running process need credentials — and where should they live? 6. List the six operating questions without looking back.