What you're actually buying
With a dedicated server you rent a physical machine. Every core, every DIMM, every drive and the network card belong to your workload. With a VPS, a hypervisor divides a host into virtual machines, each with its own allocated vCPUs, memory and storage, and you rent one of those.
FastNode runs VMware vSphere. Each server has its own kernel, its own memory and its own virtual disks backed by NVMe storage. You get root and can do anything a machine allows, short of touching the hardware.
Side by side
| Factor | VPS (VMware) | Dedicated |
|---|---|---|
| Time to first SSH | Minutes | Hours to days, depending on stock |
| Smallest useful size | 1 vCPU / 2 GB at $5/mo | A whole machine, priced accordingly |
| Ceiling | Our Hyper: 8 vCPU / 32 GB / 200 GB | Whatever the chassis holds |
| Neighbours | Other VMs on the same host | None |
| Rebuild | Reinstall an image from the portal | Remote install or a technician |
| Rollback | Snapshots | Whatever you build yourself |
| Hardware failure | Provider's problem; your VM is the unit | Your server is down until the part is swapped |
| Custom hardware | No GPUs, no special NICs | Often possible |
The noisy neighbour question
On any shared host, workloads compete for things that are hard to partition perfectly: memory bandwidth, CPU caches, storage queues. A neighbour hammering disk can, in principle, add latency to your I/O. Providers mitigate this with allocation limits, capacity planning and moving heavy users. Dedicated hardware removes the question entirely.
How much it matters depends on your workload. Web apps, APIs and CI jobs are bursty and rarely notice. A latency-sensitive trading engine or a database tuned to the microsecond might. If you need hard guarantees about tail latency, measure on a VPS with your own load, and if the numbers don't hold, go dedicated.
Measure, don't guess:
# CPU steal: time your vCPU wanted to run but the host ran something else
vmstat 1 30 # watch the 'st' column
mpstat -P ALL 1 10 # from the sysstat package, per-vCPU %stealSingle-digit steal percentages occasionally are normal on shared hosts. Sustained high steal under your own load is a conversation to have with support.
When dedicated is the right call
- Sustained full-CPU work for months. Video encoding farms, large simulations, long model training runs on CPU.
- Memory beyond 32 GB in one process. Large in-memory databases and analytics engines. Our biggest plan is 32 GB; we won't pretend otherwise.
- Specific hardware. GPUs, particular CPU generations, hardware security modules, very high-throughput NICs.
- Compliance rules that require single-tenant hardware. Some contracts specify it in writing.
- Licensing tied to physical cores. Certain commercial software licenses are cheaper or simpler on a known physical machine.
When a VPS is the right call
- Anything that fits in 8 vCPU and 32 GB. Which is most web services, APIs, CI runners, staging environments and small-to-medium databases.
- Short-lived or experimental environments. Spin up, test, reinstall, cancel.
- Many small, separated roles. Three servers for app, database and worker are easier to reason about than one big box doing everything.
- Recovery speed. A snapshot and a reinstall beat waiting for a replacement drive.
Scaling paths
With dedicated hardware, growth often means a migration to a bigger box, planned weeks ahead. With VPSs, you grow in two directions: up, by moving to a larger plan (ask support, they'll explain what the change involves), or out, by adding servers and splitting roles. Six sizes from Spark to Hyper give room to grow before the question of dedicated hardware comes up at all.
Look at the Hyper plan if you're near the top end, or the full pricing table to see each step. For why a full VM rather than a container is the isolation boundary we sell, read VMs vs containers.