The question is not "which host is best" but "how much do I want to manage". A VPS is cheapest and most flexible and you run the server. A platform is priciest per unit and you run almost nothing. Cloud sits in between.
What an app needs that shared hosting will not give you
- A long-running process. Your app stays in memory and listens on a port. Shared hosting kills processes like that.
- Root or sudo, to install runtimes, system packages and services.
- Background workers and queues for jobs that run outside a web request.
- Real cron, not a once-an-hour shared scheduler.
- A process manager (systemd, PM2, supervisor) that restarts the app if it crashes.
- Sized RAM and CPU you control, because a memory leak on a shared box gets you suspended, not scaled.
The three ways to host an app
| VPS | Cloud instance | Platform (PaaS) | |
|---|---|---|---|
| You manage | OS, security, updates, deploys | Same, plus scaling controls | Almost nothing, you push code |
| Price for the power | Lowest | Medium, pay per hour | Highest per unit |
| Scaling | Resize the box, some downtime | Snapshot, resize, add nodes | A slider or automatic |
| Best when | You know some Linux and want value | Load varies, you want snapshots and a network | Team is small, time matters more than the bill |
Sizing RAM and CPU without guessing
Start small and measure. A basic API or a side project runs happily in 1 to 2 GB of RAM and one shared vCPU. Add a database on the same box and you want 2 to 4 GB. Add background workers, a cache and real users and you are at 4 to 8 GB with two dedicated vCPUs.
Watch memory first. When an app runs out of RAM the system either kills it or starts swapping to disk, which makes everything slow. CPU tends to spike and recover. Memory pressure just degrades.
Keep the database separate early. Even a managed database on the same provider is worth it once you have real data. It gets you automated backups, point-in-time restore and the ability to resize the app and the database on their own. A crashed app should never take the data with it.
What to check before you commit
- Full root access and a clean, current Linux image
- Snapshots or images, so you can roll back a bad deploy
- Automated backups you have tested restoring
- A private network between your app and database nodes
- Clear, per-hour or per-month pricing with no surprise bandwidth bill
- An uptime commitment in writing, and a status page with history
Mahdi Hassan · Web Developer & Site Speed
If you have never run a Linux server, start on a platform for the first release and move to a VPS once the app earns enough to justify the time. Paying an extra 20 dollars a month to not debug a firewall at midnight is a good trade in year one.
Illustrative example
A SaaS that outgrew a single box
Picture an app and its database on one 4 GB VPS. It works until a marketing push triples signups. The database and the app now compete for the same memory, and slow queries freeze the web process.
Splitting the database onto its own managed instance and putting the app behind two smaller nodes fixed it, and each piece could then be resized on its own as load changed.