Websites and stores
WordPress, WooCommerce, and CMS sites past the shared-hosting ceiling.
Compute · VPS
A real VPS — dedicated cores, not oversold ones.
A VPS is a guaranteed slice of a server: dedicated vCPU, RAM, and NVMe that are yours at a flat monthly price, with root access and isolation from other tenants. VV Internet Hosting builds VPS plans on AMD EPYC with dedicated cores rather than burstable, oversold ones — so performance stays steady under load — and gives honest advice on when shared hosting is enough and when to step up to elastic cloud or a whole bare metal machine.
In short
- Dedicated, not oversold. Real vCPU on AMD EPYC, so CPU steal stays near zero and performance holds under load.
- Your own slice, with root. Guaranteed RAM, NVMe, and isolation — a private apartment, not a shared room.
- Flat, predictable price. A known monthly cost, not a meter that surprises you.
- Honest about the rungs below and above. We will say when shared is enough, or when you need cloud or bare metal.
- Portable. Standard open-source software you can move anywhere in hours — no lock-in.
The ladder
What is a VPS, and where does it sit?
A VPS is a fixed-spec virtual machine: a defined allocation of vCPU, RAM, and NVMe that is yours for a flat monthly price, with root access and isolation from other tenants. It is the step up from shared hosting where loose shared limits become guaranteed resources you control.
Shared hosting — many sites on one server, oversold by design; cheapest, fine for small sites, but no isolation and no root.
VPS — your own guaranteed slice of a server, isolated by virtualisation, with root and a flat, predictable price.
Cloud instances — like a VPS but elastic and API-driven: resize and pay by the hour.
Bare metal — the whole physical machine, single-tenant, for steady heavy load.
The useful mental picture is rungs, not categories. Each step up trades a little simplicity and cost for more isolation, control, and consistent performance, and most projects climb the ladder over time rather than picking a final answer on day one. A VPS is the rung where you stop sharing and start controlling, which is why it is where so many serious projects begin.
Real VPS or oversold — what is the difference?
This is the question that separates a VPS worth buying from one that will disappoint you, so it deserves a blunt answer. The dirty secret of budget VPS is overselling — cramming far more virtual servers onto a host than it can truly run, so benchmarks fall 30–50% under load and 'your' CPU stutters when neighbours get busy. Many oversold budget VPS plans actually perform worse than a good shared plan. The fix is dedicated vCPU on capable hardware rather than burstable, oversold cores, which is why a real VPS shows near-zero CPU steal even when the host is busy.
The terminal below is the simplest proof you can run yourself. CPU "steal" is the percentage of time your virtual processor wanted to work but the physical host made it wait — usually because the host is overcommitted. On a properly built VPS with dedicated cores it sits at zero even while the machine is busy; on an oversold one it climbs into double digits exactly when you need the performance most, during a traffic spike. We size hosts so the resources you bought are the resources you get.
It is worth saying why overselling is so common, because understanding the incentive helps you spot it. Hosts are expensive, and packing more paying customers onto each one improves the margin — right up until everyone is busy at once and the whole host degrades. Cheap headline prices are often that bet made on your behalf without telling you. We price for dedicated capacity instead, which costs a little more per plan and a great deal less on the afternoon your traffic finally arrives and the server is still fast.
# CPU steal under load — the oversubscription tell
$ mpstat -P ALL 2
CPU %usr %sys %iowait %steal %idle
all 62.4 8.1 0.3 0.00 29.2
0 71.0 9.2 0.2 0.00 19.6
1 58.3 7.4 0.4 0.00 33.9
# %steal 0.00 = your vCPU is dedicated; the host is not taking cycles.
# on an oversold VPS this climbs into double digits when neighbours run.How a VPS is isolated: KVM and your own kernel
Not all virtualisation is equal, and the kind underneath a VPS decides how isolated you really are. We use KVM, which gives each virtual server its own kernel and its own protected memory, so a neighbour cannot see your processes or read your data, and a compromised guest stays contained to itself. That is a stronger boundary than container-style virtualisation, where guests share the host kernel and isolation depends on the host getting every limit right.
It matters for performance as much as security. With true virtualisation and dedicated resources, what another tenant does on the same host does not leak into your machine — their busy database does not slow your web server, and their traffic spike does not eat your CPU. That predictability is the whole reason to leave shared hosting, and it only holds if the isolation is real rather than a few software limits stretched across an overcrowded box.
Performance: dedicated vCPU, NVMe, and what to size
A VPS is sized along three axes, and knowing which one binds your workload saves money. CPU comes in two flavours: dedicated cores that are always yours, and burstable cores shared with others that are cheaper but fade under sustained load. For a busy site, a build server, or anything that runs the processor hard for more than a moment, dedicated wins; for a small site or a quiet API, burstable is fine. We are clear about which you are getting, because the difference is invisible until the day it matters.
Storage is the axis people underestimate. NVMe is an order of magnitude faster than the SATA SSDs many budget plans still use — well over a hundred thousand input-output operations a second versus a tenth of that — and for a database or a busy CMS that gap is the difference between snappy and sluggish under load. Memory is the simplest: size it to your application's working set plus headroom, and remember that swapping to disk, however fast the disk, is always slower than having enough RAM. We help you size all three to the workload rather than to a round number.
One more practical note: more vCPU is not always faster. Many workloads — a typical website, most APIs — are bound by single-core speed and by disk, not by core count, so a plan with two fast dedicated cores and quick NVMe often beats one with eight slow shared cores. We would rather right-size you against how your application actually behaves than sell you a bigger number that does not move your bottleneck. If you are unsure, a short conversation about what you run usually settles it quickly.
Do you actually need a VPS, or is shared enough?
Often shared hosting is enough, and we would rather say so than sell you up. Be honest about the rung below, too: a small, low-traffic site is often served perfectly well by good shared hosting, and a quality shared plan can beat an oversold budget VPS. The common upgrade trigger is real traffic or revenue — roughly the point where throttling or a noisy neighbour starts costing you.
The move makes sense when you have outgrown that. A VPS is the right rung once you have outgrown shared hosting — consistent traffic, a real application (Node, Python, a database, Redis), custom server configuration, your own firewall and fail2ban, or compliance needs — but do not yet need the elasticity of cloud or the whole machine of bare metal. The signs are practical: pages that slow down when a neighbour gets busy, a plan that will not let you install what you need, an application that wants Redis or a background worker, or a compliance requirement that a shared environment cannot meet. When those appear, a VPS pays for itself in performance and control; before they do, it is mostly cost and complexity you do not need yet. We will help you read which side of that line you are on rather than push the upgrade by default.
There is a cost to staying on shared too long, though, and it is worth naming so the honesty cuts both ways. A site that has started to matter — bringing in revenue, ranking in search, serving real customers — can lose more to a throttled afternoon or a noisy neighbour during a spike than the upgrade would ever cost. So the advice is symmetrical: do not buy a VPS before you need one, and do not cling to shared once the stakes have risen. We would rather help you time the move than profit from getting it wrong in either direction.
Workloads
What people run on a VPS
The sweet spot is a real application or service that wants dedicated resources but not a whole machine, reviewed 2026-06.
APIs and web apps
Node, Python, or Go services with a database and cache on one or two instances.
Dev, staging, and CI
isolated environments you control and can rebuild at will.
Self-hosting
Nextcloud, mail, bots, Docker stacks, small models, and personal infrastructure.
Single-purpose boxes
a database, a cache, a game server, or a monitoring node.
Self-hosting on a VPS
One of the most satisfying uses of a VPS is reclaiming things you would otherwise rent by the month. A single instance comfortably runs your own file sync and storage, a password manager, a media server, automation and bots, a mail server, or a stack of Docker containers — the personal and small-team infrastructure that adds up quickly as subscriptions but costs little to host yourself.
The reason a VPS suits this better than shared hosting is control: root access, your own ports and firewall, custom software, and persistent background processes that shared plans forbid. The reason it suits it better than a hyperscaler is cost and simplicity — a flat monthly price with no per-gigabyte egress meter on the data you and your family or team actually move. We are glad to host that kind of project, and to keep the network clean and protected underneath it so your self-hosted services are reachable and safe.
A fair caution belongs here, too: self-hosting trades a subscription for responsibility. The services are yours, which means the updates, the backups, and the security are yours as well, and a neglected self-hosted box is a liability rather than a saving. That is precisely where a managed plan, or our keep-the-platform-healthy middle ground, earns its place — you keep the ownership and the cost savings while handing off the parts you would otherwise forget. We are happy to help you find that balance.
VPS, cloud, or bare metal — how do you choose?
They are three rungs of the same ladder, and the right one follows from how your workload behaves. A VPS is fixed-spec at a flat monthly price, which is a feature when your load is steady and predictable and you want a known bill. A cloud instance is the same isolated machine made elastic — resize and pay by the hour — which earns its premium only when your load actually varies. A bare metal server is the whole physical machine, single-tenant, which wins when load is heavy and constant or you need maximum performance with no neighbours at all.
Because all three live on the same hosts and the same network here, you are never choosing a vendor so much as a rung, and you can move between them as you grow. Start on a VPS, lift to elastic cloud when a launch makes your traffic spiky, or graduate to bare metal when the box is simply busy all the time — each step is a configuration change rather than a migration to somewhere new. See cloud compute → See bare metal →
If there is one rule of thumb, it is to match the rung to the shape of the load, not to ambition or to a provider's preference. Steady and known wants a VPS or bare metal; variable and unpredictable wants cloud; small and quiet wants shared. The mistake is buying the rung that sounds most impressive rather than the one that fits, and paying for capacity or elasticity the workload never uses. We would rather put you one rung lower and right than one rung higher and wasteful.
How do you get started, and can you grow later?
Getting started is quick: pick a plan, choose an operating system, and the machine is yours with root in minutes, with snapshots and an image library to give you a clean, repeatable starting point. From there you secure it, install your stack, and you are running — or, on a managed plan, we set the foundation up for you.
Growing later is deliberately painless. You can resize a plan to add CPU, RAM, or disk as your needs climb, take a snapshot before any risky change so you can roll back in moments, and when a VPS is no longer the right rung, step up to an elastic cloud instance or a dedicated machine without leaving the platform. Because it is all standard software on one network, growth is a setting you change rather than a project you survive — and if you ever need to leave us entirely, the portability of a standard VPS means you can.
Managed and unmanaged options
Unmanaged means root and full control — you run the operating system, updates, and backups. Managed means we handle the plumbing so a team without dedicated operations staff gets VPS economics without building a DevOps function. Both run on the same isolated KVM hosts. For a VPS specifically, that choice usually tracks your comfort on the command line. If you are happy to SSH in, secure the box, and keep it patched, an unmanaged plan with root is the cheapest and most flexible. If you would rather not own the operating system, a managed plan adds patching, backups, and monitoring so you can focus on the application.
There is a sensible middle ground we are glad to occupy: you run the software while we keep the platform, hardware, and network healthy and step in when something below your application breaks. Whichever you pick, the machine underneath is the same dedicated KVM guest on the same hardware — the difference is who holds the wrench, not the quality of the server.
Costs follow that division in the obvious way: managed plans carry a premium for the work we take on, while unmanaged plans are leaner because you are doing it. Neither is more "real" than the other — a managed VPS is not a lesser machine, and an unmanaged one is not a trap; they are simply two answers to how you would rather spend your time. You can also start one way and switch as your team or your free hours change, without rebuilding anything.
The single-host reality, and how we cover it
Honesty about a VPS means naming its one structural limitation. A single VPS lives on one physical host, so it shares that host's fate; we mitigate with RAID storage, redundant networking, snapshots, and off-box backups — and the path up to elastic cloud or a dedicated machine is a configuration change, not a migration. That is not a reason to avoid a VPS; it is a reason to back it up properly and to know what the next rung offers.
So we treat resilience as part of the service rather than your problem alone: RAID protects against a failed disk, redundant networking against a failed link, and snapshots plus off-box backups against the host, the rack, or your own mistakes. Because a VPS runs standard open-source software with no proprietary APIs, you can move it to another provider in hours — unlike cloud platforms whose managed services are designed to be hard to leave. That portability is real long-term value. If your application genuinely cannot tolerate a host failure, that is an honest signal to run it across our elastic cloud or a clustered setup, and we will say so rather than pretend a single VPS is something it is not.
None of this is unique to us; it is the honest shape of what a single virtual machine is on any platform. What varies between providers is whether they tell you. Plenty sell a VPS with implied invincibility and leave you to discover the single-host reality during an outage; we would rather you understand it up front, back up accordingly, and know exactly which day a higher rung becomes worth its cost. Clarity before the incident is worth more than reassurance during one.
What we run, and what we will not oversell
Our VPS plans give you dedicated vCPU on AMD EPYC, guaranteed RAM, fast NVMe, a flat monthly price, root or managed as you prefer, dual-stack IPv4 and IPv6, and the same clean, DDoS-protected network and reputation-checked IP space as the rest of our platform. It is a VPS built to hold its performance under load rather than to win a price race it can only finish by overselling the host.
What we will not do is cram the host to hit a headline price, or push a VPS on someone a good shared plan would serve better, or pretend a single virtual machine is a fault-tolerant cluster. We would rather size you to the right rung — sometimes a smaller one — and keep your trust as you climb. The whole point of a VPS is honest, dedicated resources at a predictable price, and that is exactly what we sell, with a clear path up when you outgrow it.
And the path up is genuinely a path, not a wall. Because a VPS, a cloud instance, and a dedicated server here share hardware, network, addressing, and protection, growing is continuous rather than a cliff you fall off when the plan runs out. You are not buying into a dead end that forces a painful migration the moment you succeed; you are buying the rung you need now, on a ladder built so the next step is easy when you reach it.
Questions
VPS, answered plainly
The questions people ask before stepping up from shared hosting.
What is a VPS?
A virtual private server is a fixed-spec virtual machine: a defined allocation of vCPU, RAM, and NVMe storage that is yours for a flat monthly price, with root access and isolation from other tenants. It is the rung above shared hosting, where loose shared limits become guaranteed resources you control, and below cloud and bare metal.
What does 'oversold' VPS mean, and how do I avoid it?
Overselling is cramming far more virtual servers onto a physical host than it can really run, betting that not everyone is busy at once. When that bet fails, benchmarks drop by a third to a half and your CPU stutters as neighbours get busy — visible as high CPU 'steal'. We avoid it by giving dedicated vCPU on capable AMD EPYC hardware rather than burstable, oversubscribed cores, so steal stays near zero even under load.
Is a VPS faster than shared hosting?
For a site doing real work, yes — usually several times faster and far more consistent, because you get dedicated CPU and RAM instead of competing with hundreds of accounts on one machine. But a small, low-traffic site can be served perfectly well by good shared hosting, and a quality shared plan can beat an oversold budget VPS. The honest answer depends on where you are.
Do I need a VPS or just shared hosting?
Stay on shared while your site is small and low-traffic; it is cheaper and simpler. Move to a VPS once you have consistent traffic, a real application like Node or Python with a database, custom server configuration, your own firewall, or compliance needs. The usual trigger is real traffic or revenue — roughly the point where throttling or a noisy neighbour starts costing you more than the upgrade.
VPS or cloud instance — what's the difference?
A VPS is fixed-spec at a flat monthly price; a cloud instance is the same idea but elastic and API-driven, resized and billed by the hour. Choose a VPS for steady, predictable workloads where a known monthly cost is a feature; choose cloud when your load spikes and subsides and you want to pay only for the peaks. Both run on the same isolated KVM hosts here, so moving between them is easy.
Can I move my VPS elsewhere later?
Yes, and easily. A VPS runs standard open-source software with no proprietary APIs, so you can migrate it to another provider in hours rather than rewriting infrastructure code. That portability is the opposite of cloud lock-in, and we think it is a feature worth keeping — if we stop earning your business, you should be able to leave without a penalty.
Managed or unmanaged — which should I pick?
Unmanaged gives you root and full control: you run the operating system, updates, and backups. Managed hands that plumbing to us, so a team without a sysadmin still gets VPS economics. Both run on the same hardware and network; the choice is only how much you want to operate yourself, and you can switch later.
What happens if the physical host fails?
A single VPS lives on one host, so it shares that host's fate — which is why we run RAID storage and redundant networking to reduce the risk, and help you set up snapshots and off-box backups so a bad day is recoverable. If you need to survive a host failure transparently, that is a reason to step up to our elastic cloud or a clustered setup, and we will tell you when that is worth it.
Tell us what you are running.
What it is, how much traffic it sees, and whether you want to operate it yourself — and we will size a VPS, or tell you when shared, cloud, or bare metal fits better.