Related: How to Add Payments to Your App Without Regretting It Later
Hosting gets picked early, often casually, and then stays for years. The monthly price is the least interesting part of the decision. What matters is how much of your team's attention it consumes.
The three options
A virtual private server
You rent a machine. You install everything: the runtime, the database, the web server, the certificates. You own the operating system.
Costs: a usable small server is a few dollars a month. Something that comfortably runs an app and a database is commonly in the range of 10 to 40 dollars a month.
Good for: steady predictable traffic, long running processes, background jobs, anything where you want full control or need to keep costs flat.
The real cost: your time. Security patches. Backups that are tested, not just configured. Certificate renewal. Monitoring. Log rotation before the disk fills. Being the person who gets up when it stops responding.
A managed platform
You push code. The platform builds it, runs it, handles certificates, and scales instances up and down.
Costs: commonly several times a comparable VPS. Managed databases in particular carry a large premium over running one yourself.
Good for: small teams without an operations person, projects where shipping speed matters more than infrastructure cost, anything where a day of engineer time is worth more than a month of hosting.
The real cost: money, and some flexibility. You work within the platform's model. Unusual requirements can be awkward or impossible.
Serverless
You deploy functions. They run when something calls them and cost nothing when idle.
Costs: generally charged per request and per unit of compute time. Genuinely near zero at low volume. Can be excellent or expensive at high volume depending on the shape of your traffic.
Good for: very spiky traffic, event handling, scheduled jobs, webhook receivers, APIs with long quiet periods.
The real cost: constraints. Execution time limits. Cold starts on the first request after idle. No long lived connections, which makes traditional database pooling awkward and often requires a connection proxy. Local development is less straightforward.
Count hours, not just the bill
This is the comparison people skip.
Suppose a VPS costs 20 dollars a month and a managed platform costs 100. The platform looks four times worse. Now add the time: patching, backups, monitoring, certificates, and the occasional incident. Call it four hours a month, conservatively, once things are stable.
Four hours of engineer time is worth considerably more than 80 dollars almost anywhere. The managed platform is cheaper, and it is not close.
The VPS wins when:
- You already run servers, so the marginal hour is small
- You are running several projects on one box, spreading the overhead
- Cash matters more than time, which is a real situation early on
- You need something the platform will not let you do
Serverless cost surprises
Serverless is cheap at low volume and the pricing model has sharp edges.
- Steady high traffic is often more expensive than a server that is simply always on. Serverless is priced for bursts, not for a constant load.
- Long running work is billed for the whole duration. A function waiting on a slow API is paid for while it waits.
- Data transfer out is usually charged separately and is a common source of unexpected bills.
- A retry loop can cost real money fast. A function that fails and retries aggressively will bill for every attempt. Set concurrency limits and budget alerts on day one.
Choosing
A short decision path that fits most projects:
- Is traffic very spiky, or mostly idle with bursts? Serverless.
- Do you have long running processes, websockets or background workers? VPS or a managed platform, not serverless.
- Do you have someone who enjoys running servers and has time? A VPS is a fine choice and the cheapest.
- Is it a small team focused on shipping product? Managed platform. Pay the premium and get the hours back.
- Are you unsure? Managed platform. It is the easiest to leave, because you have not built around anything unusual.
Whatever you pick
These are not optional:
- Automated backups you have actually restored from. An untested backup is a hope, not a backup. Restore one this month.
- Uptime monitoring that alerts a human. Finding out from a customer is too late.
- Error tracking. Not log files you read when someone complains. Something that tells you when the rate changes.
- A billing alert. Especially on anything usage priced.
- Deployment that is one command or one merge. If shipping is tedious, you will ship less and batch more risk into each release.
We deploy to all three depending on the project. If you want a recommendation for a specific application, describe it to us and we will give you a straight answer.
Comments