VPS vs cloud vs dedicated server: in practice, the difference comes down to three questions. How many other customers share the hardware underneath you, what holds the boundary of that sharing in place, and is your bill based on having resources or on using them? Most comparisons are either too general to help with a real decision or so technical that they leave you more confused than before. Here we open up all three models with real diagnostic commands, a comparison table and the hidden items on the bill, and finish with a simple decision framework so you know where to put your money.
What is a VPS, and what does the hypervisor do?
If we had to answer "what is a VPS" in one line: a slice of a powerful physical server that virtualization software turns into an independent server. The real hardware (processor, RAM and disk) sits in a datacenter, and a software layer called the hypervisor divides it among several customers. Each customer gets their own operating system and full root access, and as far as their software can tell, they own a complete machine.
How good that division is depends on the type of virtualization. With KVM virtualization, the industry standard, RAM and CPU cores are isolated at the hardware level, which means a resource-hungry neighbor cannot "borrow" your RAM. That is the practical answer to "what is a virtual server": an independent machine with guaranteed resources, running on shared hardware.
KVM is a module inside the Linux kernel that uses the processor's hardware virtualization extensions, Intel VT-x or AMD-V. In other words, memory isolation is enforced in the processor's own circuitry, not by a software convention. By contrast, another family of so-called "virtual servers" is really containers (OpenVZ, Virtuozzo and LXC), where every customer runs on one shared kernel: you cannot change the kernel, and overselling is easier, because the resources promised to customers can add up to more than the physical resources that exist.
systemd-detect-virt
kvm
systemd-detect-virt --container
none
# exit=1An output of kvm means a full virtual machine. If the second command returns something like lxc or openvz, you are sitting in a container, not a virtual machine; and if the first command prints none and exits with a non-zero code, there is no virtualization at all, which means you are on physical hardware.
What is a cloud server, and how is it different from a traditional VPS?
This is where most of the confusion lives. In purely technical terms, a cloud server is usually the very same KVM virtual machine. So what is a cloud server, and why does it get a separate name? The difference lies in three things, none of which is inside the server; they all sit around it. Nor is this a marketing invention: the reference document NIST SP 800-145 defines cloud computing by five essential characteristics, and three of them (on-demand self-service, rapid elasticity and measured service) are exactly what a traditional VPS lacks.
1) The billing model
You rent a traditional VPS by the month or the year; you pay for a cloud server according to what you use. You top up a wallet, and charges are deducted only for the hours the server exists. For a test environment, a short-term project or learning, that can mean paying several times less.
2) Instant, automatic provisioning
In the traditional model, you place an order and wait for someone to prepare the server. In the cloud model, creating a server is an automated operation: you pick the operating system, and less than a minute later the IP address and SSH access are in your hands. Deleting it is just as simple, and from the moment of deletion the cost drops to zero. The real value of this automation is that it turns a server into a consumable rather than an asset: instead of nursing a half-dead machine back to health, you build a fresh one and delete the old one.
3) Scalability
Have a sales peak coming up? With a traditional VPS you usually have to change the plan for the whole billing period; on a cloud server you raise RAM and CPU from the panel, and the new rate applies from that moment. But let us state honestly a fact that gets lost in the ads: vertical scaling is usually one-way. Growing is easy, but shrinking a disk is possible almost nowhere. So if you expect to return to your previous configuration after the peak, the real approach is to build a second server and spread the load across the two, not to grow and shrink a single machine.
In short, "cloud" is not a separate, magical technology. It is the same virtualization plus usage-based billing, instant provisioning and flexible resources. Mehran Host's servers work on exactly this logic: KVM and NVMe disks in an Iranian datacenter, charged by the hour from a prepaid wallet in Iranian currency.
What is a dedicated server, and when is it actually worth it?
A dedicated server means the entire physical machine is yours: there is no hypervisor and no neighbor. That gives you the most raw power and the most complete control, but it comes at a price: a monthly cost several times higher, a longer delivery time, and the fact that upgrading the hardware means opening the case, not clicking in a panel.
A dedicated server is the right choice when at least one of the following is true for you:
- Heavy, constant load: a database that genuinely fills 64 GB of RAM, or processing that keeps every core busy around the clock;
- Specific hardware requirements: a GPU, special disks, or software licenses tied to physical hardware;
- Compliance requirements: policies that state explicitly that data must not sit on shared infrastructure.
On the other hand, it carries a hidden cost: a hardware failure is no longer something the provider absorbs for you; it costs you time. A failed RAM module means someone has to go to the machine physically, and until then you are down. That is why RAID, out-of-band management access (IPMI/iDRAC/iLO) and a tested backup are not optional here.
htop that their real usage is under 20%. Before paying several times more, measure your real load on a cloud server for a week; numbers make better decisions than guesses.VPS vs cloud vs dedicated server at a glance
This table compares the three options from the angles that actually shape the decision in practice: cost, how quickly you can change things, what happens when something fails, and raw power.
| Criterion | Traditional VPS | Cloud server | Dedicated server |
|---|---|---|---|
| Starting cost | Low (monthly) | Very low (hourly) | High |
| Billing model | Fixed monthly/yearly | Pay as you go | Fixed and heavy monthly |
| Delivery time | Minutes to hours | Under a minute | Hours to days |
| Doubling the RAM | Plan change, usually with a migration | A few clicks and a restart | Ordering a part and a physical visit |
| Scaling down | Plan change | RAM and CPU usually yes, disk no | Practically meaningless |
| Isolation | At the KVM level | At the KVM level | Complete (separate hardware) |
| When the hardware fails | Depends on the host's policy | Usually moved to a healthy node | Wait until the part is physically replaced |
| Access when the network is down | Usually a virtual console | Console from the panel | Requires IPMI/iLO |
| Raw power | Good, in line with the plan | Good, and can grow | Maximum |
| Best for | Sites with a steady load | Most projects, variable load, testing | Heavy constant load, special hardware |
How can I tell which one I am on right now?
Before any comparison, establish your current situation for certain. Three short commands, run after connecting over SSH, will verify any claim you read on a sales page:
lscpu | grep -Ei '^(hypervisor|virtualization|model name|cpu\(s\))'
CPU(s): 4
Model name: AMD EPYC-Rome Processor
Hypervisor vendor: KVM
Virtualization type: fullThe "Hypervisor vendor" line appears only on a virtual machine, and the value "full" means full virtualization, which is exactly what KVM provides. Now the disk and the RAM:
lsblk -d -o NAME,ROTA,SIZE
NAME ROTA SIZE
sda 0 76.3G
sr0 1 1024M
free -h
total used free shared buff/cache available
Mem: 7.3Gi 3.3Gi 485Mi 126Mi 3.6Gi 3.6Gi
Swap: 8.0Gi 1.6Gi 6.4GiThe ROTA column means "rotational": a value of 0 is a non-rotating disk (SSD or NVMe) and 1 is a mechanical hard drive. In the memory output, the column to read is "available", not "free": Linux deliberately uses idle RAM as cache, so a low "free" value is not a sign of a shortage. The full interpretation of these numbers is in our Linux server monitoring guide.
Measure your real usage before you choose
Most of the money wasted in this market goes on resources that are never used. A week of measurement is the cheapest consultation you can buy. Track three numbers.
Load average. The uptime command gives the average load over one, five and fifteen minutes, and the yardstick is your number of cores: on a four-core server, a sustained load of 4 means the CPU is exactly saturated, while a load of 0.25 means roughly six percent of its capacity.
Steal time. The single most important number in any discussion of virtual servers. According to the proc documentation, this field is "the time spent in other operating systems when running in a virtualized environment": the time during which your virtual core was ready to work but the hypervisor had given the physical processor to someone else. It is the st column in the output of vmstat. Recent versions of procps-ng add a gu column after it, so find the column by its name, not by its position:
vmstat 1 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 1718016 497208 96064 3653092 0 1 22 17 5 5 3 1 96 0 0
0 0 1718016 498020 96064 3653100 0 0 0 0 1696 2151 4 1 95 0 0
1 0 1718016 498556 96064 3653100 0 0 60 0 1611 2023 4 1 95 0 0On a healthy server this number stays at or near zero. If it sits steadily in double digits, you have paid for a core and are getting only part of it, which is what is known as overselling. The wa column is the percentage of time the CPU spends waiting for the disk; a steadily high value there means your bottleneck is the disk, not the CPU, and buying more cores is not the answer. The tests that document overselling are in our 9 hands-on checks of VPS performance.
Peak usage, not the average. What sizes a server is the worst hour of the week. If RAM hits the ceiling every Saturday at 10 a.m. (the first working day of the week in Iran) and sits at half for the rest of the week, either size the server for that hour or add extra capacity only for those hours, which is something the hourly model makes cheap and the monthly model makes expensive.
The real cost: hourly vs monthly break-even and hidden bill items
Comparing an "hourly price" with a "monthly price" means nothing until you do the math. The formula is simple and works for any provider:
break-even hours = monthly price / hourly priceIf the number of hours your server really needs to be running is lower than this figure, the hourly model works out cheaper. For a server that is up 24 hours a day, the two models converge, and the deciding factor is no longer price but flexibility; the calculation for different usage patterns is in our hourly vs monthly server comparison. But the main trap lies elsewhere: the price on the sales page is not the whole bill.
- Traffic. How much is free each month, and what does each gigabyte cost after that? Some models count only outbound traffic, others count both directions.
- Extra IP addresses. Usually billed separately, sometimes with a minimum holding period, which means you cannot hand one back quickly.
- Automatic backups. Almost always a separate add-on with its own cost, not part of the base plan.
- Licenses. Windows and commercial control panels ride on the bill and never show up in a hardware-only comparison.
- A powered-off server. Powering off does not bring the cost to zero; the disk and the IP address are still reserved. What brings the cost to zero is deleting the server.
A dedicated server has one more item that never appears on the invoice: your time, spent monitoring disk health, replacing parts and coordinating with the datacenter.
Which model goes down less? The truth about uptime
A common misconception is that "cloud means always up". It does not: a cloud virtual machine, like any other server, is a single point of failure. What the cloud gives you is the tools to build redundancy, not redundancy itself, and the real difference between the three models lies in recovery time, not in the probability of failure:
- On virtual infrastructure, a hardware failure on the host is usually dealt with by starting the machine again on a healthy node, and what you see is an unexpected reboot.
- On a physical server, the same failure means waiting for human intervention in the datacenter: hours, and longer if the part is not in stock.
- In both cases, application-level failures (a full disk, exhausted memory, a broken config) have nothing to do with the type of server, and they are your job.
If you genuinely need high availability, the answer is not in the plan name but in the architecture: two servers in two locations and a mechanism that takes a failed destination out of rotation, at the DNS level with several A records under one name plus health checks.
Noisy neighbors, isolation and security
The old question "can a neighbor hurt me?" has a more precise answer than yes or no. Under KVM, your RAM is separated at the hardware level, and a neighbor can neither take it nor read it. But three resources remain inherently shared, and the quality of the host's management decides how fairly they are divided: CPU time, whose effect you see in steal time; disk input/output, which shows up in the wa column; and the bandwidth of the node's network port.
A dedicated server removes all three, and for compliance requirements that rule out shared infrastructure it is the only option. But let us be frank: the break-ins we see on servers in Iran almost never come through a neighbor. They come through a weak SSH password, an outdated plugin or a forgotten open port, and a dedicated server cures none of these. In all three models, Linux server security is your own responsibility.
A decision framework: ask three questions
- Is my load constant or variable? If usage rises and falls over the day and over the month, the cloud model almost always wins. If the load is heavy and even, compare prices between a large VPS and a dedicated server, including every hidden item above, not just the big number on the sales page.
- Do I really fill the resources of a whole physical server? As long as the answer is "no", the difference between a VPS and a dedicated server is, for you, mostly a difference in price, not in performance: KVM isolation gives you the same resource guarantee at a much lower cost. And "filling" is not a matter of guessing: it means a sustained load close to your number of cores, and "available" RAM that keeps running out.
- How quickly do I need to be able to change? If you do not know today what resources you will need three months from now, which is natural for a growing project, choose the option where a change takes a few clicks, not a few days. In the hourly model, a wrong guess costs a few hours of rent; in the dedicated model, it costs a contract.
The honest conclusion: for the vast majority of websites, applications and growing projects, a cloud server is the right starting point; buy dedicated hardware once data on your real usage has shown that you need it. Getting this decision wrong is not a disaster either: migrating between the three models is almost the same job, because what moves is data and configuration, not the machine. The right order of steps is in our guide to migrating a website without downtime. And if you are still on shared hosting and not sure whether it is time to move, the signs that you have outgrown shared hosting are a better starting point than this comparison.
What Mehran Host offers, and what it does not
Of these three models, what can be ordered today automatically, directly from the website, is shared web hosting on cPanel or DirectAdmin and KVM cloud servers with NVMe disks in an Iranian datacenter, with automatic provisioning and hourly charges from a prepaid wallet in Iranian currency. If your audience is outside Iran, cloud servers in Hetzner's datacenters are ordered with the same wallet.
Bare-metal dedicated servers are not offered as a ready-made plan today. If your workload genuinely needs dedicated hardware, the right path is our enterprise solutions page, so that a conversation can establish what can be provided and on what timeline. We prefer that to putting something in a price table that has no ready capacity behind it.
There are also a few things you should know, honestly, about the cloud server itself. Resizing from the panel is upgrade-only: RAM, CPU and disk can be increased and the new rate applies from that moment, but you have to restart once for the extra disk space to take full effect, and reducing resources, especially disk, is not possible. Automatic backup is a separate add-on that you switch on yourself and that is billed by the hour, and restoring a backup goes through a support ticket because it overwrites the whole disk. An extra IP address cannot be removed for two weeks after purchase.
On the other hand, three things make life easier. CPU, RAM and daily traffic graphs are built into the panel, so you do not have to build the measurement we recommended from scratch. The graphical (VNC) console opens inside the same panel and works even when the server's network is down, playing the role that IPMI plays on a physical server. And if your domain's DNS is managed here, every A record has a CDN switch next to it that hides the origin IP and serves the traffic from edge nodes in Iran, Europe and the US; the first 1 TB of CDN traffic is free.
Frequently asked questions
What is the difference between a VPS, a cloud server and a dedicated server, in one sentence?
A VPS is an isolated slice of a physical server rented by the month; a cloud server is technically the same virtual machine, but with automatic provisioning, resource changes in a few clicks and billing by the hours used; and a dedicated server means the whole machine is yours alone, with the most raw power, the highest cost and the slowest changes. Your load pattern and how fast you need to change decide the choice, not raw power.
Is a VPS slower than a dedicated server?
Not meaningfully: on comparable hardware with KVM virtualization, the overhead is usually no more than a few percent, because memory and CPU isolation are handled by the processor's own hardware extensions. Slowdowns blamed on "being virtual" almost always come from a small plan, a slow disk or an oversold host. The diagnosis is a number: if the steal time column in vmstat output stays in double digits, the problem is the host, not the technology.
Is the difference between a cloud server and a VPS just the name?
No. The underlying technology can be the same, but the experience differs: usage-based billing instead of fixed rent, instant creation and deletion instead of waiting, and resource changes without moving to another server. The NIST reference document defines cloud computing by these same characteristics: on-demand self-service, rapid elasticity and measured service. If a provider has merely named its plans "cloud" but lacks these features, it is really selling a traditional VPS.
Does powering off a cloud server bring the cost to zero?
No. With almost every provider, a powered-off server still occupies disk, an IP address and its share of RAM on the node, so most of the bill stays where it is; what really brings the cost to zero is deleting the server. So if your work pattern is "on for a few days, off for a few weeks", the right approach is to take a full backup, delete the server and build it again when you need it.
Can I start on a cloud server and move to a dedicated server later?
Yes, and that is the recommended path. Start on a cloud server, record your real usage for one to two weeks, and go by peak usage, not the average. If the data shows you have reached the ceiling of one machine, migrating is not hard: bring the destination server fully up, move the data with rsync and a database dump, test with the hosts file before changing DNS, and lower the TTL a day in advance.