The fastest core we sell
Compilers, game ticks, interpreters and query planners all spend their day on one hot thread. Adding cores does nothing for them. A faster core does, and the Ryzen 9 9950X is the quickest thing per core we can buy in volume and still keep cool.
Most workloads are not parallel. They are one hot thread waiting on one core, and the only thing that makes them faster is a faster core. That is what this line is for.
| Plan | Dedicated cores | Memory | NVMe storage | Port speed | Price | |
|---|---|---|---|---|---|---|
| R-4 Single app, comfortably | 4 | 16 GB | 200 GB | 10 Gbit/s | €29.00 /mo | Configure |
| R-8Most taken The one most people buy | 8 | 32 GB | 400 GB | 10 Gbit/s | €54.00 /mo | Configure |
| R-12 Database plus the app around it | 12 | 64 GB | 800 GB | 10 Gbit/s | €98.00 /mo | Configure |
| R-16 A whole chip, to yourself | 16 | 128 GB | 1.6 TB | 10 Gbit/s | €179.00 /mo | Configure |
Prices exclude VAT where applicable. Traffic: Unmetered, fair use.
AMD Ryzen 9 9950X · Zen 5 · up to 5.7 GHz boost · dedicated, never oversold
Thirty-four cities, twenty-nine countries
Latency figures are measured medians from our own probes, not vendor brochures. They move; the page updates when they do.
What Zen 5 is actually good at
Per-core throughput is the one hardware figure most software still cares about, and it is the one the industry quietly stopped advertising once core counts became easier to sell by the dozen.
Sixteen cores at up to 5.7 GHz, on a node that is not packed to the edge.
The 9950X gives you sixteen Zen 5 cores and thirty-two threads on a single memory domain. There is no NUMA topology to reason about, no cross-socket hop, and no scheduler decision that can quietly halve your throughput. Whatever thread is hot gets the whole boost budget it asks for.
We buy this part because the ceiling is high and the floor sits close behind it. Sustained all-core clocks on our nodes land within a few hundred megahertz of the single-core peak, since the chassis was specified for the thermal load rather than to a price. A chip that boosts beautifully for eleven seconds and then idles at base clock all afternoon is no use to anybody.
One hot thread
Build servers, game tick loops, Node and Python event loops, PostgreSQL planning and executing a single query, JVM startup. None of it parallelises, and all of it responds directly to clock speed and instructions per cycle.
Full-width AVX-512
Zen 5 executes five-hundred-and-twelve-bit vectors on a datapath of the same width instead of cracking each one in half. Encoders, cryptography, compression and anything numeric collect the difference without being recompiled.
Memory that answers quickly
DDR5-5600 across two channels, tuned for latency rather than for a benchmark screenshot. Pointer-chasing work, meaning interpreters, linked structures and graph traversal, cares far more about this than about raw bandwidth.
Cache you keep
Cores are pinned, so the L2 and L3 lines your process warms stay warm. On an oversold host that same cache is being flushed continuously by three tenants you cannot see and cannot ask to stop.
Every Ryzen node in production is a 9950X. There is no older generation quietly filling racks in the cheaper cities, and no plan whose page says Zen 5 while the hypervisor says something else.
Who should not buy this
This line is narrow on purpose. Most of the reasons people end up unhappy with it are reasons we could have given them before they paid.
Written down because it is cheaper for both of us than a refund on day six.
Your working set is over 128 GB
The largest Ryzen instance stops at a hundred and twenty-eight gigabytes, because that is what two channels of unbuffered DDR5 hold sensibly. Above it, take EPYC: registered memory, six times the channel count, and room to keep growing.
You need ECC
Ryzen nodes run unbuffered DDR5 with no error correction. For most workloads that is a non-issue. For a ledger, a week-long simulation or anything where silent corruption is worse than a crash, buy the EPYC line instead.
The job is embarrassingly parallel
If you can saturate forty-eight threads and you genuinely do not care how quick any one of them is, you are paying a premium for clock speed nobody will notice. Core-hours cost less per unit on EPYC.
You want tens of terabytes
These nodes carry NVMe and nothing else. Past roughly two terabytes the arithmetic stops working in your favour and the storage line starts making sense.
Anything involving CUDA
There is no GPU in these nodes and none can be added later. Passthrough cards live in their own line, on EPYC hosts with the PCIe topology to feed them.
You want your own hypervisor
Nested virtualisation runs here and we will not pretend it runs well. If the plan involves Proxmox, a nested cluster or a custom kernel with its own scheduler, buy metal.
How a core gets allocated
A core you buy is a core nobody else is scheduled on. Easy sentence to write, expensive one to mean, so here is the mechanism underneath it.
Overselling ratio: zero. That is a number, not a posture.
Each node has sixteen physical cores and we sell fifteen. The sixteenth runs the hypervisor, the storage stack and the monitoring agent, so our overhead never comes out of your allocation. When a node fills, the order form stops offering that site rather than squeezing one more tenant in beside you.
Threads are pinned. One instance holds a physical core together with its sibling thread, which means you are never sharing silicon with another customer through simultaneous multithreading. That trick is how sixteen cores become sixty-four on a price list, and it is the single most common lie in shared hosting.
Steal time on a healthy node reads zero and stays there. Check it yourself with `vmstat` inside the first hour. If it is not zero, open a ticket, because something has genuinely gone wrong and we would rather hear it from you than from a graph.
| Resource | How it is allocated | What is shared |
|---|---|---|
| CPU cores | Pinned; one tenant per physical core and its sibling thread | Nothing |
| Memory | Reserved at boot. No ballooning, no swap on the host | Nothing |
| NVMe capacity | Thick-provisioned when the instance is created | Nothing |
| NVMe throughput | Weighted fair queue with a guaranteed floor per instance | Headroom above the floor |
| Network port | Ten gigabits per second, dedicated to the instance | Site uplink, engineered above the sum |
Disks
The storage layout is boring, which is the highest compliment available in this part of the industry.
Enterprise drives with power-loss protection, mirrored, one hot spare per node.
Gen4 NVMe in mirrored pairs, plus a spare drive sitting idle until the day it earns its keep. Reads come off either half of the mirror. Writes are acknowledged from a cache backed by capacitors, so a power event flushes what you thought was committed instead of losing it.
Capacity is thick-provisioned. Buy eight hundred gigabytes and eight hundred gigabytes stop being available to anyone else that second, which is precisely why we cannot sell you space on a node that is already full. Thin provisioning is how hosts end up writing apologetic emails about read-only filesystems at three in the morning.
What you will measure
Sequential throughput in the thousands of megabytes per second, and enough random IOPS that the bottleneck moves back into your own application within a day of tuning.
Snapshots
Point-in-time images on separate storage, restored in seconds. Available on request at any hour. They are not a backup and we will keep saying so.
Off-node backups
Nightly, encrypted on your side before they leave the instance, written to a different city than the one the instance runs in.
What is absent
No network-attached root volume, no shared cluster filesystem under you, no storage tier that slows down because a neighbour is having a busy evening. The disks are in the machine.
Where you can have it
Ryzen is the only family we carry everywhere. If a site is lit, it has 9950X capacity, including the small ones that carry nothing else.
All thirty-four sites, twenty-nine countries. No exceptions in this line.
Choose the jurisdiction with at least as much care as the latency. For most of our customers the jurisdiction turns out to matter more, and it is the harder of the two to change afterwards. Round-trip medians from our own probes sit on the locations page, and they move when the internet does.
Three sites deserve a note. Reykjavík has a shorter path to North America than most of continental Europe, which surprises people every time. Santiago and Johannesburg are Ryzen-only for now, so anything you build there has to fit inside this line. Frankfurt’s newer floor carries 9950X exclusively, with no earlier generation racked behind it.
| If you want | Start here | Why |
|---|---|---|
| The densest site we run | Amsterdam | First site we ever lit, and everything ships there first |
| Lowest transatlantic latency from Europe | London | Shortest westbound hop in the European footprint |
| Cheapest terabyte in Europe | Bucharest | Generous transit and unfashionable rack space |
| A quiet jurisdiction | Chișinău or Panama City | Both read a subpoena very literally |
| South-East Asian users | Singapore | Default answer, and rarely the wrong one |
| Users actually in Brazil | São Paulo | Anything else adds a hundred milliseconds and an argument |
Custom ISO is available at every site. Upload an image or give us a URL, and the install runs against the same virtual media path our own images use.
Moving in
Migration is the part of hosting everyone dreads and nobody writes down honestly. This is the sequence we actually recommend, in the order we recommend it.
Median forty-seven seconds from settled invoice to root credentials.
- 01
Buy the smallest thing that proves the point
Take one instance in the site you are considering, on a monthly term, and run your real workload on it rather than a synthetic benchmark. The refund window is seven days and asks no questions, so a serious test costs you nothing but attention.
- 02
Bring your image, or use ours
Twenty-two prebuilt images are one click away, from Debian and Alpine through the BSDs. If your build depends on a kernel we do not ship, upload the ISO and install exactly what you had. Nothing about our platform requires an agent inside your instance.
- 03
Copy the data before you cut over
Ports are ten gigabits and traffic is unmetered, so an initial rsync of a few hundred gigabytes is an afternoon rather than a project. Run it twice: once to move the bulk, once to catch the delta at the point you stop writing.
- 04
Move the addresses last
Lower the DNS time-to-live a day ahead, verify the new instance on its own IP, then swap the record. Keep the old instance alive for a week. Everyone who skips this step writes to support about it later.
- 05
Resize when the numbers say so
Moving up a plan takes a reboot and a few minutes; memory and NVMe grow in place on the same node when it has room. Cores are the one resource that occasionally needs a live migration to a node with capacity, which we schedule with you rather than around you.
“Four years, two attacks, one dead NVMe replaced without me noticing. That is the entire list of events.”
When a node fails
We would rather describe the failure path plainly than imply we have engineered it out of existence. Nobody has.
Hardware dies. The interesting question is what happens in the following ten minutes.
Most failures are drives, and drives are the case we have made boring. A mirror half dies, the spare takes over automatically, the array rebuilds while your instance keeps running, and a technician swaps the dead unit at the next site visit. You usually find out because you read the notification, not because you noticed.
Whole-node failures are rarer and louder: a board, a pair of power supplies, a controller. Out-of-band monitoring notices within seconds, the instance is rebuilt from its mirrored volumes onto a standby node in the same site, and your IP addresses follow you. Typical time to boot elsewhere is under fifteen minutes.
You will be told
Notification goes out when we detect it, not when we have finished writing the explanation. The incident record on the status page is updated as things change and stays published afterwards.
Your addresses follow you
IPv4 and the routed IPv6 /64 are reassigned to the replacement instance. No DNS changes are required, and no certificate is invalidated.
The SLA applies without a form
Contractual uptime is 99.99% monthly. If we miss it, the credit appears on your account automatically. There is no claim to file and no support agent to persuade.
Snapshots are the fast rollback
Hardware failure is not the only reason to need last Tuesday back. A snapshot restore is seconds, which is why we suggest keeping one before every deployment you are unsure about.
Questions about this line
Physically pinned, and its sibling thread belongs to the same instance. You can verify it: steal time stays at zero under sustained load, and a single-threaded benchmark returns the same figure at three in the afternoon as it does at three in the morning. Nobody else is scheduled there.
We deleted the cheap tier in 2021. It produced nine out of ten support tickets and effectively all of the abuse reports, and removing it made everything else on this list possible. There is no plan to bring it back.
No. The platform is unbuffered DDR5 and we are not going to claim correction it does not perform. If your workload needs ECC, the EPYC line runs registered DDR5-4800 with correction logged where you can read it.
The port is ten gigabits per second and dedicated. Fair use on that port is fifty terabytes a month, published rather than hinted at. Cross it consistently and you get an email about a dedicated arrangement, never a surprise invoice.
Move up within the line while there is room on the node, or across to EPYC when memory rather than clock speed becomes the constraint. Cross-family moves are a fresh instance and a copy, which is why we suggest keeping your build reproducible from the first day.
No ballooning, no host swap, no compression tricks. Memory is reserved at boot and stays reserved until the instance is destroyed, including the part you are not currently using.
Take one for a week
Pick a site, pay in coin, and have root in well under a minute. If the workload does not behave the way you expected, ask for the money back inside seven days and it goes home in the asset you sent.