A VPS is powerful because it is a real computer. That sentence cuts both ways: someone must operate it. If Lesson 24.2 was the apartment tour, this lesson is the superintendent's job description. Read it before you rent anything.

Power means upkeep

On a managed platform, strangers handle patching, restarts, certificates, and disk alarms while you sleep. On a VPS, those jobs have exactly one owner until you assign one: you. None of them is exotic. All of them are real, and skipping them is how small servers fail in boring, predictable ways.

Here is the full responsibility list in plain language:

• Operating-system updates. Linux distributions ship security fixes constantly. Somebody must apply them and occasionally reboot. An unpatched server is not "stable" — it is exposed.
• User access and SSH keys. You reach a VPS over SSH, using cryptographic keys instead of passwords. Somebody must create accounts, install the right public keys, remove old ones, and never share a private key.
• Firewall rules. A firewall decides which network ports the world may knock on — typically SSH, HTTP, and HTTPS, and little else. Open ports are promises; every extra one is risk.
• Running process restarts. When your app crashes or the machine reboots, something must start it again — a process supervisor, a container restart policy, a startup script. Hope is not a restart policy.
• Domain and HTTPS setup. Pointing a domain at the server's IP and installing a certificate so browsers get encrypted HTTPS. Certificates expire; renewal must be automatic and monitored.
• Backups. Copies of what you cannot afford to lose: application data, databases, uploaded files, configuration. A backup you have never restored is a rumor.
• Disk space. Disks fill — with logs, uploads, database growth, cached packages. A full disk stops writes, crashes processes, and corrupts the worst things first.
• Logs. Timestamped records of what each process did. Somebody must decide where logs go, how long they are kept, and how to read them when something breaks.
• Monitoring and cost alerts. Is the service up? Did the nightly job succeed? Is spending drifting? Alerts tell a human before users become the monitoring system.

That is the VPS bargain, stated once: freedom to run anything, responsibility for keeping it running. Class 25 will show platforms that take some of these jobs back — in exchange for constraints. For now, own the list.

Reading is safe; changing is consequential

Beginners hear that list and freeze, afraid to touch anything. So draw the line that professionals use every day:

• Reading / inspecting is safe. Checking whether a process is running, reading logs, viewing disk usage, looking at firewall rules, reviewing backup dates. Look freely; looking breaks nothing.
• Changing production is consequential. Editing DNS records, rotating or deleting secrets, deleting servers or volumes, running database migrations, changing firewall or access rules, deploying new code, publishing. Each deserves a pause, a second pair of eyes, and a way back.

The rule of thumb: *if you cannot undo it in five minutes, do not do it alone at midnight.* Proposals and plans are cheap; executed actions on live systems are expensive. This distinction returns in every later part — agents, publishing, money — because capable builders know when an action needs deliberate review.

Teach your future AI assistant the same boundary. An agent may read status and logs broadly; it should never change DNS, secrets, production data, or deployment settings without your explicit, reviewed approval.

The outage that teaches everything: the disk-full collector

Take the daily financial-data collector from the last lesson. It runs beautifully for months on a small VPS. Each run appends to a log file. Nobody rotates the logs. Nobody watches disk usage.

One Tuesday the disk hits 100%. The collector wakes at market close, tries to write its fresh results, and fails — no space left. The web product keeps serving, cheerfully displaying yesterday's data as if it were today's. Uptime checks stay green. The failure is silent for three days until a user asks why the numbers never change.

The lesson is not "never use a VPS." The lesson is measure the simple things that can stop a process: disk percentage, job success, data freshness. A one-line disk check and a log-rotation rule would have caught this in week one. Most VPS outages are not exotic hacks. They are full disks, expired certificates, forgotten updates, and crashed processes nobody restarted — the checklist at the top of this lesson, ignored.

The minimal runbook: your server's instruction sheet

Professionals compress all of this into a runbook — a short document that tells a tired human (or a fresh AI session) how to keep the system alive. Minimal does not mean vague. Yours needs five facts:

1. What runs. Service names, what each does, where it lives on the machine. 2. How to see if it is healthy. The exact status command or health URL, and what "healthy" looks like. 3. Where logs are. File paths or dashboard links, per service. 4. How to restart it. The exact safe restart command — and what never to restart casually. 5. Who owns credentials. Where secrets live (environment settings, provider vault — never the repo) and who may touch them.

That last point connects directly to Project Control: instructions in Markdown, kept in a source-controlled repository, are how a future human or AI session understands the system without guessing. Your runbook is the first Project Control document for infrastructure. Write it while the setup is fresh, not after the outage.

Visual: the responsibility checklist

Picture a single VPS icon in the center with four grouped checklists radiating outward, each label large enough to read in the article text:

• Access: SSH keys, user accounts, firewall rules.
• Reliability: restarts, domain/HTTPS, backups, disk space.
• Visibility: logs, monitoring, job-success signals.
• Cost: spending alerts, resource sizing, renewal dates.

The caption underneath: *renting the computer rents every box.* If a box has no owner, it owns you.

Practical exercise: write RUNBOOK.md

Create a file called RUNBOOK.md for your project (real or practice VPS — even a planned one). Use exactly these four headings:

# Runbook — [project name]

## What runs
## How to check it
## How to restart it
## What must never be changed casually

Fill each with two to five lines:

• What runs: name each process (web app, collector, worker), one line on its job.
• How to check it: the exact first status check per service — a health URL, a status command, a log tail. State what healthy output looks like.
• How to restart it: the exact safe restart step per service.
• What must never be changed casually: DNS, secrets, production database, firewall rules, deletion — list yours.

Finish line: a RUNBOOK.md with all four headings filled, specific enough that a stranger could name the service and its first safe check.

Verification: hand it to another person — or paste it into a fresh AI session with no other context — and ask: "What runs here, and what is the first safe status check?" If they can answer without guessing, the runbook works.

Common failure mode: writing "restart the server" as the only fix. Rebooting the whole machine is a blunt instrument that hides the real fault and interrupts everything else. Name the *service* restart first; reserve full reboots for when you understand why.

Check your understanding

1. List at least eight operating responsibilities a VPS owner inherits, in your own words. 2. What is the difference between reading a server and changing it? Give two examples of each. 3. In the disk-full story, why did uptime checks stay green while the product was broken? 4. What are the five facts a minimal runbook must contain? 5. Why do runbooks belong in Markdown under source control rather than in someone's memory? 6. Which infrastructure changes should an AI agent never make without deliberate human review?