A single VPS, however well specified, is one : if the physical machine under it fails, your site is down until it comes back. Cloud hosting, in the engineering sense, isn’t a place or a marketing label; it’s a way of building that answers exactly that problem: resources pooled from a cluster of servers, separate storage that lets your server run on another machine, an API that creates and deletes servers in minutes, and billing by consumption. The difference doesn’t show on an ordinary day. It shows in two questions: what happens when something breaks, and how you grow when the load doubles.
01What “cloud” means in engineering terms
The word “cloud” is stamped on everything today, even on a plain VPS. But a cloud platform, in the sense that matters to an engineer, combines five properties:
- Pooled resources: CPUs, memory and storage from dozens of servers are managed as one pool, and your server can run on any node in it.
- Storage separate from compute: Your server’s disk lives on a distributed or networked storage system such as Ceph, not on the disks of the machine running it. That’s what makes it movable.
- Automatic recovery: When a node fails, restarts its servers on healthy nodes within minutes. And moves a running server to another machine ahead of scheduled maintenance without stopping it.
- Elasticity through an API: You create servers, disks and load balancers with a single command or a tool like Terraform, and delete them when the load is gone.
- Metered billing: You pay for compute by the hour or the second, and for storage and outbound data by the gigabyte.
So if a provider tells you its service is “cloud”, ask three questions: where does my server’s disk live? What happens to it if the physical machine fails? Can I create and delete servers through an API? The answers tell you more about what you’re buying than the name does.
02Failure domains: what goes down when something breaks?
A failure domain is everything that goes down together when a single component fails: a disk, a physical machine, a rack or a whole data centre. An honest comparison between a VPS and the cloud starts from this table:
| Failure | Traditional VPS | Single cloud server | Several servers behind a balancer in two regions |
|---|---|---|---|
| Disk failure | Keeps running if the disks are in RAID 10 | Keeps running; distributed storage replicates the data | Keeps running |
| Physical machine failure | Down until the machine is fixed or the server is restored | Restarted on another node within minutes | Visitors notice nothing |
| Scheduled host maintenance | A reboot or a short outage | Usually live-migrated, no downtime | Visitors notice nothing |
| Data centre outage | Down | Down if it lives in one region | The other region takes the load |
| Accidental delete or broken update | Only backups protect you | Only backups protect you | Only backups protect you |
Look at the last row: neither high availability nor replication protects you from your own mistakes. A wrong delete or an update that corrupts the database is copied instantly to every live replica. That’s why independent backups remain a requirement in every architecture; we cover building them in a separate article on VPS storage.
Notice too that a single cloud server is down for minutes when its node fails, because restarting on another node means a fresh boot. “Visitors notice nothing” comes from the last column alone: more than one copy of your application running at the same time.
03Vertical and horizontal scaling
There are two ways to grow. Vertical scaling means making the server itself bigger, with more cores and memory: it’s simple and needs no change to the application, may need a short reboot depending on the provider and the resource, and its ceiling is the size of the physical machine. means adding identical servers and spreading requests across them, so there’s practically no ceiling, and the site survives if one of them goes down.
But horizontal scaling requires a stateless application, meaning any server can handle any request. In practice that means:
- User sessions live in Redis or the database, not in files on the server’s disk.
- Uploaded files live in shared storage or S3-compatible object storage, not in a local folder.
- The database runs on its own server, or a cluster with a primary and read replicas.
- Code is deployed to every server with the same tool and the same version.
At the front sits a balancer that spreads requests and drops a failed server. Here’s a simple example of with Nginx in front of two application servers for a clinic appointment platform in Beirut, mawid-beirut.com:
# /etc/nginx/conf.d/mawid.conf on the balancerupstream mawid_app { least_conn; server 198.51.100.11:8080 max_fails=3 fail_timeout=10s; server 198.51.100.12:8080 max_fails=3 fail_timeout=10s;}server { listen 80; server_name mawid-beirut.com; location / { proxy_pass http://mawid_app; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_next_upstream error timeout http_502 http_503; }}
Mind two limits. Open-source Nginx checks backends passively, meaning it detects a failure when real requests fail; active health checks need a tool such as HAProxy. And a single balancer puts you back in a single failure domain: cloud platforms offer redundant managed balancers, while in an architecture you build yourself you need two balancers sharing a floating IP, or failover at the DNS level.
04Cost models
A VPS is a fixed price for fixed resources: you know your bill before the month starts, and you pay it whether the server runs at 5% or 90%. In the cloud you pay for consumption, so you win when the load fluctuates and lose when it stays flat around the clock, because the hourly cloud price is usually higher than its share of a monthly plan. And a cloud bill has many line items:
| Cost item | VPS | Public cloud |
|---|---|---|
| Compute | A fixed monthly price per plan | By the hour or second, per server |
| Traffic | A monthly allowance in the plan | Outbound data usually billed per GB |
| Load balancer | You build and run it yourself | A managed service with an hourly fee and a traffic fee |
| Database | On your server, run by you | A managed service priced above a comparable server |
| Backups and snapshots | Backup space included with the plan at some providers | Billed per GB per month |
| Bill predictability | Easy | Needs monitoring and budget alerts |
An example shows the difference: a ticketing platform for a festival in Tripoli, mahrajan-tripoli.com, runs a light load for eleven months, then its load jumps twentyfold during sales week. A server sized for the peak all year is waste, and capacity you add for the week and then remove costs less. A store with a nearly flat daily load, on the other hand, is usually cheaper on a right-sized VPS plan than on its cloud equivalent.
There are middle paths between the two models. CoreVPS servers are billed by the day with no contract, so you can add a server for a peak week or a load test, then delete it and pay only for its days. That isn’t per-minute autoscaling, but it covers most peaks whose date you know in advance.
05When a VPS is enough and when you need the cloud
| Situation | Best fit | Why |
|---|---|---|
| A company site or store with a predictable daily load | VPS | Fixed cost; a rare few minutes of downtime is acceptable with good backups |
| Development and test environments | VPS | Cheap and easy to rebuild |
| Load that multiplies in known seasons | VPS plus temporary servers, or the cloud | Add capacity for the peak, then remove it |
| An app that can’t tolerate minutes of downtime, under a strict SLA | Cloud, or several servers in two data centres | Needs more than one live copy in more than one failure domain |
| Unpredictable load, like an app that suddenly goes viral | Cloud | Autoscaling adds servers without intervention |
| A team with no systems engineer | Managed services | Running a VPS or a cloud cluster is daily work that takes expertise |
The deciding question isn’t “which is better?” but “how many minutes of downtime can I tolerate, and how much data can I afford to lose?” Those two numbers settle the architecture; we work through them in a separate article on hosting by company size.
06Cloud-style resilience from VPS servers
You don’t need a full cloud platform to get out of a single failure domain. Here’s a common pattern for a platform like mawid-beirut.com:
- 01Two application servers in two different data centres, say Germany and Finland, running the same code version.
- 02A primary database in one data centre and a replica in the other, promoted when the primary fails.
- 03Uploaded files synced between the two servers, or kept in shared object storage.
- 04A DNS record with a short TTL, 60 to 300 seconds, at a DNS service that supports health checks and failover, or a load balancer in front of both.
- 05An independent daily backup stored outside both servers.
CoreVPS servers are available in six data centres, and every plan includes backup space outside the server, so you can build this pattern from two mid-size plans. The price is that you run the redundancy yourself: syncing, database promotion and failover testing. And if you see the word Cloud in a service name such as Illevante’s Nexus Cloud, it’s a cloud backup service launching soon, not compute servers.
- ProblemThe site went down even though you have two servers
- FixCheck the entry point: a single balancer, or a DNS record with a long TTL, puts you back in one failure domain.
- ProblemAfter failover both databases accept writes
- FixThat’s split brain. Don’t promote the replica automatically without a mechanism that fences off the old primary; start with manual promotion.
- ProblemUsers get logged out at random after you add a server
- FixSessions are stored on each server’s disk. Move them to Redis or the database before you spread the load.
07Before you decide
Start with one right-sized VPS and independent backups: that’s enough for most sites. Then write down two numbers: the most downtime you can tolerate, and the most data you can afford to lose. If acceptable downtime is hours, a VPS with a tested restore is enough. If it drops to minutes, prepare your application for horizontal scaling first: sessions off the server, files in shared storage, a separate database.
Once your application is stateless, moving to several servers or to a cloud platform becomes a cost decision, not a rebuild.
