You now know two places work can run: your local workshop and a serverless function that wakes on demand. Class 24 added a third: the VPS, a rented computer you operate. This lesson gives you the decision framework that turns those options — plus one more — into a deliberate choice instead of a habit.

The seven choice axes

Every workload can be described along the same axes. Run through them before choosing anything:

1. Duration. Milliseconds, seconds, or minutes per unit of work? 2. Frequency. Once a day, a few times an hour, or hundreds of times a minute? 3. Traffic pattern. Steady trickle, predictable schedule, or unpredictable bursts? 4. Persistent connections. Does anything need to stay connected — a bot holding a chat session open, a live feed, a websocket-like channel? 5. Operational appetite. How much server care will you actually do — updates, restarts, log rotation? Be honest. 6. Data locality. Does the work need to sit near particular data, users, or a compliance boundary? 7. Budget shape. Do you prefer near-zero cost at rest with per-use charges, or a flat predictable monthly rent?

Write these on the workload cards from Class 24 if you have not already. They are the inputs; the four homes below are the outputs.

The four homes

Managed application platform — e.g. Railway. You push code; the platform builds it, runs it as a web service or worker, wires the networking, and handles much of the plumbing. Less control than a VPS, far less operating burden. The right default when you need an always-on service but do not want to be a sysadmin yet.

Serverless / edge platform — e.g. Vercel or Cloudflare. Strong for request- and event-driven work inside platform constraints: short executions, stateless assumptions, per-use pricing. Superb when traffic is bursty or mostly idle. Wrong when work runs long, needs persistent connections, or outgrows the limits.

VPS — e.g. DigitalOcean or Hetzner. A rented virtual computer that stays online and that you operate. Full control over installed software, long-lived processes, custom networking. The price is the operations role from Class 24: updates, keys, firewall, restarts, backups, disk, logs, cost alerts. Choose it when control genuinely matters, not by default.

Local machine. Development and private experiments only — Lesson 25.1 settled this. A dedicated always-on Mac mini counts as a local server with the same responsibilities as a VPS plus physical ones. Never the public answer by accident.

| | Managed (Railway) | Serverless / edge | VPS | Local |

|---|---|---|---|---|

| Stays on without you | Yes | Wakes per event | Yes, you keep it on | Only with server discipline |

| Ops burden | Low | Lowest | High | High (plus physical) |

| Long / persistent work | Workers yes | Constrained | Yes | Possible, fragile |

| Cost shape | Usage + flat tiers | Near-zero at rest | Flat monthly rent | Hardware + power + risk |

Five worked examples

Watch the axes decide:

• Brochure site. Static pages, no login, traffic trickles. Duration: milliseconds. Connections: none persistent. Verdict: serverless/edge static hosting. A VPS here is an apartment rented to store a postcard.
• Authenticated SaaS dashboard. Logins, per-user reads from Postgres, form writes, bursty daytime traffic. Verdict: serverless functions plus managed Postgres. Idle nights cost nearly nothing; bursts scale without you.
• Daily report generator. Once a day, runs a few minutes, reads sources, writes a report row, notifies. Verdict: scheduled function or a small managed-platform worker with a cron trigger — *not* an always-on server burning rent for one daily run.
• Realtime service. Holds many connections open simultaneously, pushes updates the moment they arrive. Verdict: this is where serverless constraints bite. A managed platform with long-lived processes or a VPS you operate fits better, because persistent connections need something that stays awake.
• Large file-processing pipeline. Users upload big files; each takes minutes of CPU to convert, chunk, and embed. Verdict: never inside the request. Upload lands in object storage, a queue holds the job, a worker on a managed platform or VPS processes it. (Lessons 25.5 and 26.3 build both halves.)

Start simple, earn complexity

The governing rule: start simple, earn complexity. The first reliable version a real user can touch beats self-managed infrastructure chosen for a future that may never arrive. Every team that outgrew a simple home did so with revenue, traffic graphs, and a concrete limit to point at. Teams that start complex get the operations burden on day one and the benefits never.

Practical exercise: write your deployment decision

Write one paragraph for one real project, using this exact form:

Two filled examples to calibrate:

Finish line: one paragraph in the exact form, naming the home, the workload, the trigger, the accepted tradeoff, and the reconsider trigger.

Verify: hand the paragraph to someone unfamiliar with the project. Can they restate your tradeoff and the condition that reopens the decision? If not, one of the blanks is still a slogan.

Common failure mode: choosing a VPS "so we can do anything later." Option value is not free — it bills monthly in rent and weekly in maintenance. Start with the smallest home that fits today's workload; the reconsider sentence is what protects tomorrow.

Check your understanding

1. Which two axes most strongly push a workload away from serverless toward a VPS or managed worker? 2. Why does a daily three-minute job argue against an always-on server? 3. What does Supabase supply, and what must still run elsewhere? 4. State the "start simple" rule in your own words and say what earns added complexity.