Every side project reaches the same fork: paste an API key into a managed platform, or rent a five-dollar server and own the whole machine. The debate around this choice is mostly tribal noise. Strip it down to what each option genuinely costs — money, attention, failure modes — and the right answer falls out of three properties of your app: traffic shape, statefulness, and how much operations you enjoy.
What serverless platforms actually charge#
Managed platforms (Vercel, Netlify, Cloudflare-style runtimes) price per use: requests, bandwidth, function invocation time, build minutes. At small scale they're unbeatable — zero dollars for hobby traffic and, critically, zero hours of maintenance.
The costs arrive as your project grows:
- Bandwidth and function pricing scales steeply. A traffic spike from one viral link is either a triumph or an invoice, depending on plan headroom.
- Build minutes add up on frequently-pushed repos.
- Platform coupling is the quiet line item: framework-specific features, proprietary caching layers, and config conventions make migrating later a real project rather than a config change.
None of this makes managed hosting bad. It makes it metered — you trade predictable bills for zero ops until scale forces renegotiation.
What a VPS actually charges#
A modest cloud VM runs $4–12/month and will serve surprising amounts of steady traffic — a containerized app behind a reverse proxy handles millions of requests monthly without breaking a sweat. Self-hosting stacks like Coolify have collapsed setup from weekend ritual to an afternoon: git push deploys, TLS provisions itself, containers restart under policy.
But the sticker price lies by omission. The real costs:
- Patching and upgrades — OS, runtime, dependencies. Monthly, forever, unskippable.
- Backups and recovery — nobody's problem until the day they're everyone's only problem. Automated, off-server, tested.
- Monitoring — something must notice when the process dies at 2 a.m., because nothing else will.
- Security surface — SSH, firewall, certificates, every open port is yours to defend. Managed platforms outsource all of it; self-hosting inherits all of it.
An hour a month is realistic for a simple well-built setup; that hour is the actual price of the cheap server.
The state question nobody asks early enough#
Traffic shape matters less than where your data lives:
- Stateless apps (static sites, standard web apps with external databases) move anywhere; choose freely, change later cheaply.
- Serverful state — local file writes, in-memory sessions, SQLite files on disk — behaves completely differently across models. Serverless filesystems are ephemeral and multi-instance; anything written locally evaporates or diverges. Self-hosted containers are also ephemeral across redeploys unless you mount volumes. Either way, durable state belongs in purpose-built storage (managed database, object storage, Redis) — which conveniently makes the app portable again.
This site is a worked example: content lives in git, publishing commits through an API, view counts go to Redis when durability matters — so the app itself stays stateless and host-agnostic, deployable to either model at will.
A decision table that actually decides#
| Your situation | Lean |
|---|---|
| Hobby traffic, no ops appetite | Serverless, free tier |
| Spiky/unpredictable traffic | Serverless (elasticity is the product) |
| Steady traffic, cost-sensitive | VPS |
| Data-residency or privacy requirements | Self-hosted |
| Deep framework-specific features used | Stay on matching platform |
| Learning how servers work | VPS, unironically |
| Multiple small apps | One VPS consolidates them all |
The honest hybrid most people land on#
Mature projects usually stop choosing: static and dynamic edges on managed infrastructure where elasticity pays for itself; steady workloads, databases, cron jobs, and media processing on one or two owned machines where predictability pays. Both sides deploy from the same repo via CI. The skill worth building isn't loyalty to either camp — it's keeping apps stateless, containerized, and configurable by environment variables, so each workload can slide to whichever economics fit it this year.
Choose for the next twelve months, not forever. Everything gets easier when neither answer has to be permanent.
Related: reading unfamiliar codebases helps when inheriting someone else's hosting decisions, and security basics covers the patching half of that VPS hour.
