Last lesson you named the gap: your product needs a place to stay awake after your laptop closes. Now meet the most literal answer — renting a computer in a data center and keeping your processes running on it.

VPS, without mystique

A VPS (virtual private server) is a rented virtual computer that stays online and that you operate.

Unpack that. A cloud provider owns big physical servers in a data center. Software divides each physical machine's CPU, memory, and disk into isolated virtual computers — each one behaves like its own machine, with its own operating system and files, walled off from its neighbors. You rent one slice, usually by the month, and you can run your own processes on it: start them, stop them, install software, open network ports.

Two concrete examples, so this is not abstract:

• DigitalOcean Droplets — virtual machines you create, resize, rebuild, and reach over the network, with DigitalOcean's docs describing CPU, memory, disk, and networking options.
• Hetzner Cloud — a second provider offering the same category: rented cloud servers with console, network, and snapshot controls.

Do not memorize either dashboard. The durable idea is vendor-neutral: a VPS is a remote Linux computer you operate. Providers change interfaces and prices; the concept — your OS, your processes, your responsibility, someone else's power and network — stays put.

Cheaper options students actually use

If price is the constraint, these are the names that come up again and again from builders and Reddit threads — all in the same VPS category, different tradeoffs on RAM, CPU, locations, and docs:

• Hetzner Cloud — very strong price-to-performance, especially on CPU; EU-based, great API/CLI. Check live CX-line pricing before trusting old comparisons.
• Contabo — leads on RAM-per-euro; good when a Docker stack or self-hosted app needs memory headroom on a budget.
• DigitalOcean — not the cheapest, but the best docs and one-click image marketplace when setup speed matters.
• Vultr — wide range of sizes plus GPUs and managed extras, 30+ locations, competitive pricing with generous egress.
• OVHcloud — European provider with a broad catalog and unlimited-egress VPS lines; often mentioned for EU data-center choice.
• Hostinger — beginner-friendly VPS tiers frequently recommended for first servers.

Prices move (Hetzner adjusted several lines in mid-2026), so treat any dollar figure as a snapshot: open the pricing page, match RAM/CPU/disk/transfer to your workload from Lesson 24.4, and compare like-for-like before you rent.

What a VPS actually gives you

Renting a VPS buys four things:

1. An operating system you control. Usually Linux. You choose what is installed: Python version, database client, web server, Docker, cron jobs. 2. Guaranteed slices of CPU, RAM, and disk. Your process gets its share even when neighbors are busy — that is the "private" in the name. 3. A public network address. Strangers on the internet can reach your machine at a stable IP, which a domain name can then point to. 4. Control over installed software and running processes. Long-lived programs stay up: an API server, a bot, a scheduled collector, a background worker.

That combination fits work that must persist between visits:

• a long-running API serving your research product;
• an always-on bot holding a persistent connection;
• a data collector waking on schedule (where the source's terms permit it);
• an MCP server your agents call as a tool;
• a background worker chewing through queued jobs;
• a scheduled fetcher writing fresh records for the web layer to read later.

The pattern: something must be awake or must wake itself even when no visitor has the site open. A laptop cannot promise that. A VPS is built for exactly that promise — with data-center power, network, and remote recovery behind it.

Think of the classic metaphor: managed hosting is a hotel room — cleaned, constrained, someone else runs the building. A VPS is a rented apartment. You arrange the furniture, paint the walls, install what you want — and you fix what breaks inside your four walls.

Linux vs Windows, and which environments you will meet

When you create a VPS you pick an operating system image. The two families you will see:

• Linux (usually Ubuntu LTS or Debian). The default for almost every AI, web, API, worker, and MCP-server workload in this course. No license fee, CLI-first, enormous documentation, Docker and most server tooling assume it. If you have no reason to choose otherwise, choose Ubuntu LTS.
• Windows Server (Microsoft). Needed only for Windows-only software — legacy .NET Framework apps, some enterprise tools, Remote Desktop workflows. It costs more (the license is baked into the hourly price) and you operate it largely through Remote Desktop rather than SSH.

You will also see environment flavors around that choice: a plain OS image you configure yourself, a pre-built application image (e.g. "Docker on Ubuntu"), and managed variants where the provider hides more of the OS. The category is the same — a virtual computer — the difference is how much setup is done for you.

How to *use* Linux or Windows Server day-to-day — users, permissions, services, patching, firewalling — is out of scope for this course. You do not need to become a sysadmin here. What you need is the selection rule and one reassurance: if you are comfortable on a Mac, you can manage Linux. macOS and Linux share Unix roots — the terminal, ssh, files and folders, permissions, bash/zsh commands, package installs — so the skills from Class 6 transfer directly. Windows Server is the odd one out; pick it only when the software demands it.

The same question in a different location: the Mac mini agent machine

Many readers already own the alternative: a Mac mini assigned to run coding agents, scripts, an MCP server, browser automation, or a small home-lab service. Once you give a machine those jobs, stop thinking of it as a desktop. It is a dedicated local server — the same infrastructure question, answered at home instead of in a data center.

That is fine, but it comes with non-negotiable conditions. If the job must be reachable or run continuously, the Mac mini needs all six of these:

1. Continuous power — plugged in, not on a strip someone switches off. 2. Always-on internet — a connection that survives the night. 3. A stable network path — router and firewall rules that actually let outside traffic (or your agents) reach it, and that survive a router reboot. 4. Sleep disabled for the intended workload — the machine must not nap mid-job. 5. Enough disk space — logs, downloads, and databases grow silently. 6. A recovery plan after reboot or outage — which processes restart automatically, and who restarts the rest?

Miss one and you have a hobby box, not a server. The VPS exists precisely because data centers handle most of this by default.

Mac mini vs. VPS, honestly

Neither is universally better. They trade different strengths:

Read the last row twice: both columns require operations. A VPS does not eliminate work; it moves the work into an environment designed for remote operation. A Mac mini keeps the work local — plus adds physical chores.

The key advantage of local: physical control. Sensitive project files, private experiments, and development tools stay under your roof, on hardware you can touch and unplug. For some privacy and hardware-specific jobs that matters more than anything.

The key disadvantage of local: you become a small data center. A home internet outage at 3 a.m. takes your agent or service down. A power blip reboots the machine while you are traveling. A router firmware update quietly closes the port your service needs. Each is survivable — but each is yours to notice and fix.

A story: the daily financial-data collector

Make it concrete. Your ByeBuy product shows fresh market context each morning. Behind it sits a small collector: it wakes at market close, fetches the day's permitted figures, stores results in the database, and goes quiet. The web product simply reads yesterday's stored rows.

Nobody visits the site at market close. Nobody clicks "run collector." The job must fire on a clock, write to the database, and log success — visitor or no visitor.

A VPS fits naturally: the collector lives where power and network are boring, wakes on schedule, and the web layer reads its output. A dedicated Mac mini *could* run the same collector — and should, if local control over the data or tooling is the deciding factor. But choose it for that reason, not because it eliminates operational work. The schedule, the logs, the disk growth, the restart plan — all of it follows you home.

Freedom versus responsibility: the preview

Here is the honest price tag, and the bridge to the next three lessons:

• A VPS gives you freedom — any runtime, any schedule, several services on one box — in exchange for responsibility: updates, access, restarts, backups, monitoring.
• A dedicated Mac mini carries similar responsibility *plus* a physical location: power, network, and presence are yours.
• Managed and serverless platforms (Class 25) remove some of that responsibility in exchange for constraints: time limits, stateless assumptions, provider rules.

There is no free option. There is only the tradeoff you choose on purpose — which is exactly what Lesson 24.4 teaches you to name before you rent anything.

Practical exercise: does your project need one?

Open INFRASTRUCTURE-NOTES.md and add a section titled ## VPS?. Answer in four to six sentences:

1. Name one workload in your project that must stay running or wake itself (collector, bot, worker, MCP server — be specific). 2. State how often it runs and what triggers it (schedule? persistent connection? queue?). 3. Say why a request-driven function might or might not be enough for it. (If you cannot answer yet, write what you would need to learn — that counts.) 4. Add one line in this exact form: "Mac mini, VPS, or managed platform?" followed by your current lean and the tradeoff behind it — power, network, privacy, and maintenance, each in a few words.

Finish line: a VPS? section with a named workload, its rhythm, a function-vs-server judgment, and a one-line hosting lean with reasons.

Verify: could a stranger read the section and say what must stay awake and why? If the workload is vague ("the backend"), tighten it to one process.

Common failure mode: choosing "VPS by default" because it sounds serious. Serious is naming the workload first. The next two lessons give you the responsibility list and the classification tool to check your instinct.

Check your understanding

1. What does "virtual," "private," and "server" each mean in VPS? 2. Name the four things a VPS gives you, and two workloads that genuinely need them. 3. When should you pick Linux vs Windows Server for a VPS, and why is Mac familiarity enough to start on Linux? 4. Why is the durable idea "remote Linux computer you operate" rather than loyalty to DigitalOcean or Hetzner? 4. What turns a Mac mini into a "dedicated local server" — and what are its six non-negotiables? 5. What is the key privacy advantage of the Mac mini, and the key reliability disadvantage? 6. In the collector story, why does the job need a home beyond visitors' browsers?