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 on one shared vCPU. Put a database on the same box and that rises to 2 to 4 GB. Once background workers, a cache and real users are in the mix, you are looking at 4 to 8 GB and a couple of 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
One box, then a marketing push
App and database share a single 4 GB VPS. Fine for months. A campaign triples signups over a weekend, and now the two are fighting for the same memory. A single slow query is enough to lock the web process, and the whole thing hangs.
The database moved to its own managed instance and the app went behind two smaller nodes. From then on each half could be sized on its own as demand shifted.