Cloud servers explained: VPS, dedicated servers and managed hosting (2026 guide)

A cloud server and a VPS (virtual private server) are usually the same technology sold under two names: a physical machine sliced up by a hypervisor into virtual machines, each with its own operating system, IP address and root access. The honest answer to "cloud server vs VPS" is that they overlap heavily. What actually changes your outcome is how much of the physical machine you really get — shared or dedicated vCPU, shared or dedicated NVMe storage — plus whether anyone manages it for you and which region it sits in. This guide walks through shared hosting, VPS, cloud instances and dedicated (bare-metal) servers, then covers managed vs unmanaged, regions, backups, SLAs, a decision table by workload, and what buying "managed cloud" through a partner actually means compared with buying direct.

What is a server, and what changes when you rent one?#

A server is just a computer that stays on and answers requests over a network — the same job whether it is a NPR 40,000 second-hand desktop under a desk or a rack of AMD EPYC processors in a data centre. What changes when you rent server capacity is not the software your app runs; it is three things: how much of the physical hardware is reserved for you alone, who is responsible for keeping the operating system patched and the backups working, and how far away the machine is from the people using your app.

Almost every hosting decision — shared hosting vs VPS vs dedicated, managed vs unmanaged, one region vs another — is really a decision about those three variables: isolation, responsibility and distance. Keep that in mind and the rest of the terminology gets much easier.

Shared hosting, VPS, cloud instances and dedicated servers#

These four options sit on a spectrum from "many tenants, little control" to "one tenant, full control."

Shared hosting puts many customers on one server behind a control panel like cPanel. You don't get root access, and one customer's traffic spike or badly written plugin can slow everyone else down — the classic "noisy neighbour" problem. It's inexpensive and fine for low-stakes sites, but you have almost no control over performance or configuration.

VPS uses a hypervisor (such as KVM) to split one physical server into several virtual machines, each with a fixed slice of vCPU, RAM and disk, and full root access. This is the workhorse tier for most business applications: enough isolation and control to run a real stack (web server, database, cache), at a predictable monthly cost.

Cloud instances are built on the same virtualisation idea as a VPS, but the commercial model is different: billing is usually by the hour or minute, instances are easy to create, resize, snapshot and destroy through an API or dashboard, and they sit inside a broader platform with extras like block storage, load balancers and image templates. The line between "VPS" and "cloud instance" has blurred — many providers, OVHcloud included, sell both a fixed-plan VPS range and a flexible Public Cloud instance range from the same underlying infrastructure.

Dedicated (bare-metal) servers give you the entire physical machine. Nobody else's workload can compete with yours for CPU cycles, memory bandwidth or disk I/O. You get more raw and more consistent performance for the same specification, at a higher fixed price, and resizing usually means moving to different hardware rather than a few clicks.

For a closer look at how to choose between these four, including a "not ideal for" case for each, see VPS vs dedicated server vs cloud hosting.

Cloud server vs VPS: is there actually a difference?#

In most real-world cases, no — a "cloud server" and a "VPS" are the same virtual machine technology. The label a provider uses often says more about their marketing than the hardware underneath. What is worth checking, regardless of the label, is:

• Is the vCPU shared or dedicated? (covered next)
• Is billing fixed monthly or usage-based? Usage-based billing suits workloads that scale up and down; fixed billing is easier to budget.
• What's included in the platform around it? Snapshots, private networking, load balancers and an API for automation are common on "cloud" platforms and less common on budget VPS plans.
• Which region options exist, and is a service level agreement published for that specific product line?

Ask these four questions and the "cloud server vs VPS" label stops mattering — you're comparing what you actually need.

Shared vCPU vs dedicated vCPU: why "4 cores" doesn't always mean 4 cores#

A vCPU (virtual CPU) is a slice of a physical CPU core allocated to your virtual machine. How that slice is allocated varies more than most buyers realise:

• Shared or "burstable" vCPU means your virtual machine is scheduled onto a physical core alongside other tenants' virtual machines, time-sliced by the hypervisor. You get good average performance and can sometimes burst above your baseline, but a busy neighbour can slow you down at the worst possible moment.
• Dedicated vCPU means a physical core (or thread) is reserved for your virtual machine alone. Performance is more consistent and predictable, which matters for CPU-bound work like video encoding, report generation, CI build agents or anything with a strict response-time requirement.

Neither option is "wrong." A low-traffic marketing site rarely notices shared vCPU contention. A payment API or a batch job with a deadline notices it immediately. When you compare quotes, ask the provider directly whether vCPU is shared or dedicated on the plan you're looking at — it is rarely obvious from the plan name alone.

Why storage type matters: NVMe vs SATA SSD#

NVMe (Non-Volatile Memory Express) is a storage protocol built for flash memory, replacing the older SATA/AHCI protocol originally designed for spinning hard drives. In practice, NVMe drives handle far more input/output operations per second (IOPS) with lower latency than SATA SSDs, which matters most for databases, search indexes and anything with many small, random reads and writes rather than a few large sequential ones. OVHcloud's VPS range, for example, states its NVMe storage delivers speeds up to six times faster than standard SSDs. For a static website this difference is barely noticeable; for a busy PostgreSQL or MySQL database, it is often the single biggest lever on perceived speed.

Managed vs unmanaged: who patches the OS at 2am?#

An unmanaged server gives you root access and nothing else — you (or your developer) are responsible for OS updates, security hardening, firewall rules, monitoring, backups and troubleshooting when something breaks, at any hour. A managed server or managed cloud service means a provider or partner takes on some or all of that ongoing work.

This single decision affects your costs more than almost any spec choice, because the "hidden" cost of unmanaged infrastructure is staff time, not a line item on an invoice. We cover this in detail, including a responsibility table and a method for costing your own time against a managed fee, in managed vs unmanaged VPS. Once a server is managed, keeping it hardened against common attacks is an ongoing job in itself — see our Linux server hardening checklist for what that actually involves.

Regions and latency: where should the server live?#

Every extra kilometre between your server and your user adds physical travel time to every request. For a business with customers in Australia and Nepal/South Asia, region choice is a genuine design decision, not an afterthought. As an OVHcloud reseller, the regions we deploy client infrastructure into most often are Sydney, Singapore, Mumbai, Frankfurt, London and Canada — all real OVHcloud regions. Which one is right depends on where your users actually are, and — for some businesses — where data is required or expected to stay.

We cover the physics of latency, how to measure it yourself with ping, mtr and curl instead of trusting a marketing chart, and the difference between data residency and data sovereignty in choosing a server location.

Backups: "included" doesn't always mean "restorable"#

Almost every VPS and cloud provider advertises "backups included." What that usually means is a daily snapshot of the disk, retained for a short rolling window, stored on the same platform as the server itself. That is useful for recovering from your own mistake (a bad deployment, an accidental delete) but it is not a disaster-recovery plan, because a platform-level failure can take the snapshot down with the server.

A real backup strategy follows the 3-2-1 rule (three copies of your data, on two different types of storage, one of them off-site) and is judged on two numbers: RPO (how much data you could lose) and RTO (how long a restore actually takes) — and it is only proven once you've actually run a test restore, not just a successful backup job. We go through all of this in backups that actually restore.

SLAs: what 99.9% actually promises#

An SLA (service level agreement) is a contractual uptime commitment with a defined remedy — usually a partial credit on your invoice — if the provider misses it. As an example of how this works in practice: OVHcloud commits to 99.9% monthly availability on its VPS range, and to 99.95% or 99.99% depending on the dedicated server range, with service credits of 10%, 30% or 100% of the monthly fee depending on how far availability fell short, under OVHcloud's VPS and dedicated server service level agreements.

Two things are easy to miss:

• An infrastructure SLA covers the hardware and network, not your application. If your server is up but your app has crashed, or a plugin update broke your site, that is outside the SLA entirely.
• A credit is not compensation. Losing 30% of one month's hosting fee rarely comes close to covering the cost of a few hours of downtime for a business that depends on its site or app.

This is exactly the gap that a managed service is meant to close: monitoring that notices a problem before your customers do, and a team that responds to it, rather than a credit that arrives weeks later. See 99.9% vs 99.99% uptime for the maths on exactly how much downtime each SLA tier allows, and what downtime really costs a business. Our own service commitments as a managed provider are set out separately in our service level agreement.

Which one does your workload actually need?#

If you want the fuller version of this comparison, with an honest "not ideal for" case for each option and a decision flow, read VPS vs dedicated server vs cloud hosting. If your main question is really about right-sizing a specific app rather than choosing a category, how to size a server for your web app covers measuring CPU, memory, I/O and concurrency before you buy.

Buying direct vs buying managed cloud through a partner#

Every server described above can be bought two ways.

Buying direct means opening an account with an infrastructure provider — OVHcloud, AWS, Azure, Google Cloud, DigitalOcean and others all sell this way — and becoming the account holder yourself. You get their portal, their published pricing, their support ticketing system, and their billing (often in EUR or USD, on a foreign-issued invoice). You are responsible for choosing the right plan, hardening the server, monitoring it, configuring backups, and responding when something goes wrong, or for finding and managing someone who will.

Buying managed cloud through a partner means a company sets up, hardens, monitors, backs up and supports a server running on infrastructure it doesn't own. That's our model: we resell and manage OVHcloud infrastructure across the Sydney, Singapore, Mumbai, Frankfurt, London and Canada regions. We don't own data centres, hardware or network backbone — OVHcloud does — and we're not a registered cloud or data-centre provider in our own right. What we add is the work around the infrastructure: initial setup and hardening, firewall configuration, backup configuration, uptime monitoring, and — depending on the level of service — 24×7 patching and response, tuned configuration, monthly reporting, or a named DevOps engineer running CI/CD and zero-downtime releases. Billing is in NPR, AUD or USD, with one accountable team to call instead of a support ticket queue — which also sidesteps the foreign-currency card limits that make paying an overseas provider directly impractical for a Nepal-based business; see buying cloud servers from Nepal for that side of the picture. See current plans and prices for each level.

There's also a middle option: "bring your own cloud." Some clients prefer to keep their own account with OVHcloud, AWS, Azure, Google Cloud or DigitalOcean — for ownership, portability, or an existing enterprise agreement — and have us manage it as if it were ours. This gets you the management without changing who holds the underlying account.

Neither path is objectively better. Buying direct is cheaper on paper and gives you full control, provided someone on your team can actually do the ongoing work well. Buying managed is a way to get that work done by people who do it full-time, with a single point of accountability, in your own currency. See our cloud hosting overview and cloud servers or dedicated servers pages for what that looks like for each server type.

A short glossary#

• Server — a computer dedicated to running software and answering requests over a network, physical or virtual.
• Hypervisor — software that splits one physical server into multiple isolated virtual machines.
• vCPU — a virtual CPU core allocated to a virtual machine; may be shared (time-sliced with other tenants) or dedicated (reserved for you alone).
• VPS — virtual private server: a virtual machine with a fixed slice of vCPU, RAM and disk, and root access.
• Cloud instance — the same underlying technology as a VPS, usually billed by usage and part of a larger platform with APIs and extra services.
• Bare metal / dedicated server — a physical server with a single tenant and no hypervisor layer shared with anyone else.
• NVMe — a storage protocol for flash memory, faster than the older SATA/AHCI protocol used by standard SSDs, especially for random, small I/O.
• Region — the geographic location of a data centre where your server runs, which determines physical distance (and therefore latency) to your users.
• SLA (service level agreement) — a contractual uptime commitment with a defined remedy, usually a service credit, if it isn't met.
• RPO / RTO — recovery point objective (how much data you could lose) and recovery time objective (how long a restore takes); see backups that actually restore.
• Managed services — ongoing patching, monitoring, backup management and incident response carried out by a provider or partner rather than by you.

What to do next#

If you're still deciding between server types, start with VPS vs dedicated server vs cloud hosting for a workload-by-workload comparison, or cloud servers and dedicated servers to see how we configure and manage each. If you already know roughly what you need, current plans and prices is the fastest way to see what fits your budget.