When it’s worth trading a shared VPS for your own hardware

If you’re on a shared VPS, it’s worth considering if you’re still on the right setup, or if it’s time for your own hardware. Here’s a comparison, and where each one wins.

The neighbor is the whole point

On a shared VPS, your threat model includes tenants you didn’t pick. Januscape is a use-after-free in KVM’s shadow MMU. A guest with root can corrupt the host’s shadow page tables and run code in the host context, which is a full guest-to-host escape. The boundary you’re trusting is the hypervisor, and the exploit runs underneath it. Hardening your guest or your firewall rules doesn’t touch it, because the way in isn’t through your VM. It was also the first KVM escape demonstrated against both Intel VMX and AMD SVM, so this wasn’t a single-vendor quirk.

A “dedicated CPU” plan doesn’t move that boundary. Pinned vCPUs stop you fighting neighbors for cycles, but you’re still scheduled by the same host kernel and the same KVM instance as everyone else on the box. That solves resource contention, not the fact that you’re sharing the host, and the attack surface you care about, the host kernel and hypervisor, is the same either way.

A single-tenant hardware removes the untrusted guest itself. With no co-tenant, there’s no hostile VM to run a guest-to-host escape from, so the whole class is gone. It won’t make your own kernel or your applications bug-free, you still patch like everyone else, and if you run your own untrusted nested guests you reintroduce the risk yourself. It removes the one vector you never had any control over, another tenant’s VM.

Cheaper on paper

On sticker price the shared VPS wins. Entry VPS runs in the low tens of dollars a month, and your own hardware starts several times that. If you’re small or still scaling into real traffic, the shared plan is the right call.

Downtime is where that flips. The public Januscape PoC doesn’t stop at escaping, it has the potential to impact the host kernel and take every VM on that physical machine down at once, yours included, with nothing on your part to trigger it causing a denial-of-service (DoS), and the researcher who found it, Hyunwoo Kim (@v4bel), says a separate unreleased build enables attackers to execute code on compromised hosts. Once an hour of downtime costs you more than the monthly gap between the two plans, the sticker price stops being the real number to judge the cost by.

Your maintenance window has other people’s names on it

Everyone had to take the fix, so patching itself is a wash. The difference is who can force a reboot. A host-kernel use-after-free like this isn’t something you reliably hot-patch, since live patching is built for small self-contained fixes rather than deep MMU changes, so remediation means rebooting the physical host. On your own box, that reboot runs on your schedule and the provider’s. On a shared host, the provider has to drain and reboot the whole machine to patch every tenant at once, and each of those tenants’ exposure is now on your maintenance calendar.

Peak traffic is when the neighbors show up

Performance is the other cost of sharing. On a shared host you carry the noisy-neighbor tax, the CPU steal you see when the hypervisor can’t schedule your vCPUs, plus contention for memory bandwidth, last-level cache, and storage IO. It surfaces as latency variance, and it tends to land during your busy hour rather than at 3am, because that’s likely when the whole box is loaded. Watch steal time on a shared VPS during a spike and you’ll see it. On single-tenant hardware the full machine is yours, quiet rack or slammed. If your load is light and flat you may never care. If you have peaks that move revenue, this part pays for the move on its own.

Moving off doesn’t mean starting over

Outgrowing a commodity VPS usually means the next step is a structurally different platform. You’ll need a dedicated host for your workload but still work like a cloud, this is what we called Cloud Dedicated. Cloud Dedicated keeps the operational model you already have. It’s still virtualized, with the same tooling, root access, and managed support, but the hypervisor runs on hardware that’s yours alone, so there are no co-tenants, and you don’t need to babysit the box yourself. None of your day-to-day operations change, and it starts small enough that you size to current load instead of jumping to a tier three sizes too big.

You don’t have to make a big thing of this. For plenty of setups a shared VPS is still the right answer, and Januscape doesn’t change that. It’s a good reminder that “who else is on my hardware” is a question you should be able to answer. If losing a few hours would really set you back, better to know before the next one of these lands than after.

---