Variable or bursty load
Traffic that spikes and subsides, or seasonal peaks, where paying only for what you use beats a fixed machine sized for the maximum.
Compute · Cloud
Elastic cloud, with guaranteed resources and honest bandwidth.
Cloud compute is virtual machines you spin up in minutes and pay for as you use them. VV Internet Hosting runs KVM instances on AMD EPYC and NVMe with dedicated, guaranteed CPU and RAM — not aggressive oversubscription — root access, dual-stack networking, and flat, honest bandwidth instead of hyperscaler egress markups. We will also tell you plainly when bare metal is cheaper for your load, and when a hyperscaler's breadth fits you better.
In short
- Elasticity is the product. A machine in minutes, resize on demand, snapshots, pay-as-you-go — what bare metal cannot do.
- Guaranteed, not oversold. KVM with dedicated CPU and RAM, so performance stays predictable under load.
- No egress games. Flat, fair bandwidth instead of the outbound markups and lock-in hyperscalers are known for.
- Cloud is not always the answer. Steady or high-egress load is usually cheaper on bare metal — we will say so.
- Hybrid is welcome. Elastic layer in the cloud, steady layer on dedicated hardware, on one clean network.
What is cloud compute, and how is it different from a server you rent?
At its simplest, it is a computer you summon with an API call. Cloud compute is virtual machines running on shared physical hosts, given to you in minutes and billed by what you use. A serious VPS uses KVM virtualisation — kernel-level isolation with dedicated, guaranteed CPU and RAM rather than aggressive oversubscription — on AMD EPYC hosts with NVMe storage, with root access and a dedicated IPv4. The point is elasticity: provision, resize, snapshot, and tear down on demand, which bare metal cannot match.
The contrast with a dedicated server is the whole point. A bare metal machine is one physical box, entirely yours, at a fixed monthly price — unbeatable for steady load, but you wait for it and you pay for all of it whether or not you use it. A cloud instance is a slice of a shared host you can grow, shrink, or delete in minutes and pay for by the hour. The real product is speed and flexibility: a machine in minutes instead of hours, the ability to add CPU, RAM, or storage on demand, snapshots and templates for quick rebuilds, and pay-as-you-go billing that drops in quiet periods. For workloads whose size you do not yet know, or which spike and subside, that elasticity is worth more than the lower unit cost of a fixed server. So the question is never which is better in the abstract; it is which fits the shape of your workload, and that is the question this page is built to answer honestly.
One more distinction matters in practice: time. With a dedicated server you buy a fixed quantity of compute for a fixed period, so the planning happens up front and changing your mind is slow. With cloud you buy an option to use compute, which you exercise and release as you go, so the planning happens continuously and cheaply. That shift — from a big decision made once to many small decisions made as you learn — is the real reason teams reach for cloud early, and the real reason they sometimes outgrow it later.
The case for cloud
When does cloud actually win?
Not always — but in these situations the elasticity is worth more than the lower unit cost of a fixed server, reviewed 2026-06.
Speed and experimentation
Early-stage products and dev/test environments where capacity is unknown and you need to spin up, fail fast, and change your mind cheaply.
Many small, separable services
Carving one budget into many isolated VMs, each sized to its job, rather than one large box.
Lower operational burden
When a managed option — patching, backups, monitoring — matters more than squeezing out the last of the performance.
What unites these is variation. Cloud earns its premium when your need for compute moves — up and down with the day, or simply upward fast and unpredictably as you grow — because elasticity only pays when there is something to flex against. When the demand is flat and known, that same premium turns into pure overhead, which is exactly the case the honest sections further down make. The skill is telling which world you are in before you commit, and we would rather help you do that than sell you the wrong shape.
How fast can you scale, and what does pay-as-you-go mean?
Fast enough that scaling stops being a project. A new instance is ready in well under a couple of minutes, not the hours a physical server takes to rack and provision, and growing one is a single call that adds CPU, RAM, or disk without rebuilding it. Snapshots let you freeze a known-good state and clone or roll back to it in moments, and templates turn a tuned setup into a repeatable starting point. The practical effect is that capacity decisions become reversible — you can try a bigger machine for an afternoon and shrink it again if you were wrong.
Pay-as-you-go means you are billed for what you actually run, by the hour, rather than for a fixed box sized to your worst day. For a workload that is busy at noon and idle at midnight, or that ramps for a launch and subsides after, that is the difference between paying for the peak around the clock and paying for it only when it happens. The honest flip side, covered below, is that for a workload which is simply busy all the time, a fixed monthly machine is usually cheaper — elasticity is only a saving when there is variation for it to track.
None of this elasticity is exotic or fragile; it is the ordinary day-to-day of running on a platform built for it. The aim is simply that capacity stops being a thing you agonise over and becomes a dial you can turn, which is precisely what a fixed server cannot give you.
The platform
How ours is built: KVM, guaranteed, on EPYC and NVMe
The difference between a cloud you can trust under load and a cheap VPS that stutters is whether the resources are real.
Underneath, our cloud is virtual machines running on shared physical hosts, given to you in minutes and billed by what you use. A serious VPS uses KVM virtualisation — kernel-level isolation with dedicated, guaranteed CPU and RAM rather than aggressive oversubscription — on AMD EPYC hosts with NVMe storage, with root access and a dedicated IPv4. The point is elasticity: provision, resize, snapshot, and tear down on demand, which bare metal cannot match. Cloud VMs sit on the same network as everything else: clean, reputation-checked IP space, dual-stack IPv4 and IPv6, anycast DNS, and edge DDoS absorption — so moving between cloud and bare metal does not mean changing the quality of the network underneath.
That last point is easy to undervalue until you have lived without it. On many platforms a cheap VM and a serious server come with different network quality, different IP reputation, and different protection, so moving up means re-earning trust from scratch. Here the instance inherits the same clean addressing and the same edge absorption as a dedicated machine, so a workload can start small on a VM and grow onto bare metal without its deliverability or its resilience resetting on the way.
# provision an instance — ready in seconds, not hours
$ curl -X POST https://api.vvih.com/v1/instances \
-H "Authorization: Bearer $TOKEN" \
-d '{ "plan": "kvm-4", "region": "eu-central", "image": "ubuntu-24.04", "ipv6": true }'
{ "id": "ins_7f3a", "status": "provisioning", "vcpu": 4, "ram_gb": 8, "ready_in": "~70s" }
# scale it up later — no rebuild, guaranteed resources
$ curl -X PATCH https://api.vvih.com/v1/instances/ins_7f3a -d '{ "plan": "kvm-8" }'
{ "id": "ins_7f3a", "vcpu": 8, "ram_gb": 16, "status": "resizing" }Storage, snapshots, and backups
Storage is where a lot of cloud value and a lot of cloud surprises live. Our instances sit on local NVMe, so disk latency is low and consistent rather than the variable performance of network storage shared with strangers. You can attach more space as you grow, take snapshots to capture a working state before a risky change, and restore from them quickly when something goes wrong.
Snapshots are not backups, though, and we are clear about the difference. A snapshot lives near the instance and protects against your own mistakes; a real backup lives somewhere else and protects against the instance, the host, or the region having a bad day. We help you set up both — fast local snapshots for everyday safety and off-box backups for genuine disaster recovery — because the worst time to discover the distinction is after you needed the second kind. Object storage for large, less-active data rounds out the picture when it fits.
Security and isolation on a shared host
A fair question about any cloud is what "shared host" means for your security. The answer is kernel-level isolation: KVM gives each virtual machine its own kernel and memory space, so one guest cannot see or reach another's, and a busy or compromised neighbour cannot read your data. Dedicated, guaranteed resources mean a neighbour also cannot starve you of CPU or memory the way an oversold host allows.
Where your requirements are stricter than multi-tenancy can satisfy — certain compliance regimes, or simply a preference for physical isolation — the honest answer is a single-tenant machine rather than a VM, and we will point you to bare metal instead of stretching a shared host to fit. For everything in between, the instance is yours: root, your own firewall, your own keys and encryption, and a network that keeps hostile traffic and dirty IP space away from you. Security is a shared responsibility, and we are clear about which half is ours and which is yours.
None of that absolves you of the basics, and we will not pretend it does: weak passwords, unpatched software, and exposed services are still the most common way anything gets compromised, on any platform. What the network gives you is a clean, defended foundation; what you bring is sensible operation on top of it. We are glad to advise on hardening, but the honest division of labour is worth stating plainly so nobody mistakes a good platform for a substitute for care.
What about the egress bill everyone complains about?
This is where most cloud bills go wrong, so it deserves a plain answer. Hyperscaler egress is the cost teams forget to model: outbound data is marked up far above its actual cost — by some accounts many multiples over — and it doubles as lock-in, because leaving means paying to move every gigabyte out.
We do not play that game. Bandwidth is priced flat and fairly, so a traffic spike is not a surprise invoice and moving your data out later is not a penalty designed to keep you from leaving. It is worth knowing why the hyperscaler bills balloon more broadly, too: The FinOps Foundation estimates roughly a third of cloud spend is wasted on idle and over-provisioned resources where there is no active cost governance. Between wasted idle capacity and outbound markups, a cloud bill can drift far above what the work actually costs — which is exactly the gap honest pricing and a willingness to recommend bare metal are meant to close.
It is worth being concrete about why this matters beyond the monthly total. Egress charges quietly shape architecture: teams contort their designs to avoid moving data, keep copies they do not need, or stay on a provider purely because leaving would cost a fortune in transfer fees. Pricing bandwidth fairly removes that distortion, so you can design for what is actually best — serve your users, move your backups off-site, switch providers if we stop earning your business — without a meter punishing every byte that crosses the boundary.
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. The right choice is mostly about your team. If you have people who are comfortable running Linux, an unmanaged instance with root is the most flexible and the cheapest. If you would rather not own patching, backups, and monitoring, a managed instance hands that to us so you can spend your time on the application instead of the operating system.
Either way, the machine underneath is the same isolated KVM guest on the same hardware and the same network — managed or unmanaged is a question of who operates it, not of getting a lesser server. You can also start unmanaged and move to managed, or the reverse, as your team and your free time change.
There is a middle path worth naming, too. Plenty of teams want to run their own application but would rather not be woken at three in the morning by a failed disk or a kernel update gone wrong. For them, an unmanaged instance with a clear support relationship — we keep the platform, hardware, and network healthy while you keep the software — often fits better than full management, and we are happy to draw that line wherever it suits you rather than forcing an all-or-nothing choice.
When should you not use our cloud?
Often enough that it is worth a whole section, because the honest answer sells less cloud. Two cases point you to our own bare metal instead, and one points you away from us entirely.
Steady, predictable load
Round-the-clock workloads at known size, where a fixed monthly price beats per-hour billing and there is no hypervisor tax.
Heavy, sustained egress
Traffic-heavy services where flat bandwidth on dedicated hardware avoids per-gigabyte cloud egress charges.
Maximum, consistent performance
Databases and latency-sensitive work that want the whole machine and no noisy neighbours.
A broad managed-service catalog
When you genuinely need a large menu of managed databases, queues, serverless, and proprietary services wired together — breadth we do not pretend to match.
Vast global reach
Dozens of regions and edge locations for a truly worldwide footprint beyond the regions we operate.
For the first two, a single-tenant AMD EPYC server is usually cheaper and faster than any instance we could sell you, and we will route you there. See bare metal → For the last, we would rather lose the sale than pretend to be a hyperscaler.
None of this is reluctance to sell cloud; it is the same logic that makes cloud worth buying when it does fit. A provider that routes every workload into instances regardless of shape is optimising for its own invoice, not your bill or your performance. We would rather be the people who tell you to buy less, or buy elsewhere, and keep your trust for the workloads where our cloud genuinely is the right answer.
The hybrid answer, and why teams repatriate
The most useful pattern is rarely all-or-nothing. The sensible pattern is hybrid: keep the elastic, variable layer in the cloud and move steady, traffic-heavy workloads (databases, analytics, delivery) to dedicated hardware. It is mix-and-match by workload, not an all-or-nothing choice. That is exactly what the wider market is doing: Repatriation is now mainstream: industry surveys put about 70% of organisations as considering moving workloads off hyperscale cloud, with around a third already repatriating some — usually steady, high-egress workloads — while keeping variable ones in the cloud.
The honest caveat runs the other way too. Repatriation is not for everyone — early-stage teams that do not yet know their needs should stay in the cloud and keep the flexibility to change direction; ownership pays off once usage is steady and large. The point is not that cloud is bad or bare metal is virtuous; it is that the bill and the performance both improve when each workload runs where it belongs. We can host both halves on one network and help you draw the line, which is a good deal more useful than insisting everything live in whichever box we would rather sell.
In practice drawing that line is less daunting than it sounds. It usually starts with one obvious candidate — a database carrying steady load, or a delivery tier moving a lot of bytes — that plainly belongs on dedicated hardware, while the parts that scale with traffic stay elastic. You do not have to plan the perfect split on day one; you move the workloads whose shape is clear and leave the rest until their pattern reveals itself, and because both halves live here, each move is a configuration change rather than a migration to a new vendor.
What we run, and what we will not pretend
We run KVM cloud instances on AMD EPYC and NVMe with guaranteed CPU and RAM, root or managed as you prefer, dual-stack IPv4 and IPv6, snapshots and quick resizing, and flat bandwidth, in the regions we operate — sitting on the same clean, DDoS-protected network as our bare metal. It is cloud built for predictability rather than for a low headline price that climbs once you are committed.
What we will not pretend is to be a hyperscaler. We do not have a catalog of hundreds of managed services or a region on every continent, and if your architecture truly depends on that, we will tell you so. What we offer instead is honest, elastic compute with guaranteed resources and fair bandwidth, a clear path to bare metal when that is cheaper, and a team that would rather size you correctly than book the largest invoice. That is the trade we think most teams actually want.
And as everywhere else, the scoping is meant to be legible. You will know what an instance includes, how bandwidth is priced, and where cloud stops being the cheaper answer, before you commit — so the platform is something you can reason about rather than a meter that surprises you. Predictable economics are not a small feature in cloud; for many teams they are the whole reason to choose a provider honest about them.
Questions
Cloud, answered plainly
The questions teams ask before they pick cloud over a server.
What is cloud compute?
It is virtual machines running on shared physical hosts, handed to you in minutes and billed by what you use. A serious cloud VPS uses KVM virtualisation — kernel-level isolation with dedicated, guaranteed CPU and RAM rather than aggressive oversubscription — on AMD EPYC hosts with NVMe storage, with root access and a dedicated IP. The defining feature versus a dedicated server is elasticity: you provision, resize, snapshot, and tear down on demand.
How is cloud different from a dedicated server?
A dedicated (bare metal) server is one physical machine that is entirely yours at a fixed price; a cloud instance is a slice of a shared host you can resize and pay for by the hour. Bare metal gives maximum, consistent performance and flat cost for steady load; cloud gives speed and flexibility for variable load. Neither is better in the abstract — they suit different workloads, and we run both.
Do your cloud instances have guaranteed resources?
Yes. We run KVM with dedicated CPU and RAM rather than overselling hosts, because kernel isolation and guaranteed resources are what keep performance predictable under sustained load. Oversubscription is how cheap VPS plans look attractive and then stutter when a neighbour gets busy; we would rather size honestly so the machine you buy is the machine you get.
Will I get a surprise egress bill?
No. Hyperscaler egress — outbound data marked up far above its real cost — is the charge teams forget to model, and it doubles as lock-in because leaving means paying to move every gigabyte out. We price bandwidth flat and fairly, so a traffic spike is not a billing event and moving your data out later is not a penalty. What you see is what you pay.
When should I use bare metal instead?
When your load is steady and round-the-clock, when you serve heavy sustained traffic where flat bandwidth beats per-gigabyte pricing, or when you want maximum consistent performance with no hypervisor overhead and no neighbours. For those, a single-tenant AMD EPYC server is usually cheaper and faster than cloud, and we will point you there rather than upsell instances you do not need.
When is a hyperscaler the better choice?
When you genuinely need a broad catalog of managed services — many managed databases, queues, serverless, and proprietary glue wired together — or a truly worldwide footprint across dozens of regions. We do not pretend to match that breadth. If your architecture depends on it, a hyperscaler is the right tool, and we will say so instead of pretending otherwise.
Can I run a hybrid setup?
Yes, and for many teams it is the smart answer: keep the elastic, variable layer on cloud instances and move steady, traffic-heavy workloads like databases and analytics to dedicated hardware. Because both live on the same network, with the same clean IPs and DDoS absorption, splitting a workload across cloud and bare metal is straightforward rather than a migration project.
Managed or unmanaged — which do I pick?
Unmanaged gives you root and full control: you run the operating system, updates, and backups. Managed means we handle that plumbing, so a team without dedicated operations staff still gets cloud economics without building a DevOps function. Both run on the same isolated KVM hosts; the choice is simply how much you want to operate yourself.
Tell us how your workload behaves.
Whether it spikes or stays steady, how much it sends, and what you would rather not operate — and we will size cloud, bare metal, or a mix of both.