Choosing

Five lines, one decision

Every line here is fast. The question is never which is best, it is which one your bottleneck is actually in, and that is a question about your workload rather than about our hardware.

Fleet

Plan17

from€29

sites34

Deployment47 s

Start with the workload

The table below is the one we use internally when a ticket asks what to buy. It is blunt on purpose, because a hedged recommendation is worth nothing to somebody holding a budget.

Find your row. If nothing matches, ask support and describe the job in two lines.

Workload	Ryzen	EPYC	GPU	Storage	Metal	Why
Single hot thread	Buy this	Slower	Pointless	Pointless	If tails matter	Nothing but clock speed and instructions per cycle helps a thread that cannot be split
Working set over 128 GB	Will not fit	Buy this	Host only	No	From 256 GB up	Two memory channels stop being enough, and registered ECC starts to matter at this size
Web app with a database beside it	Buy this	When it grows	No	No	Rarely	Most of these are one busy core and a few dozen gigabytes, which is exactly the Ryzen tier
Many concurrent expensive queries	Runs out of cores	Buy this	No	No	For hard latency budgets	Twelve memory channels keep forty-eight threads fed; two channels do not
48-hour fine-tune	No	No	Buy this	No	No	A whole card passed through, kept for the length of the job, with no scheduler in front of it
Serving a quantised model to users	No	No	Buy this	No	No	VRAM decides the answer, and twenty or forty-eight gigabytes is a different product from a CPU
Seed box with 40 TB	No room	No room	No	Buy this	Only if you insist	Bulk capacity behind an NVMe tier, on an unmetered port, at a price NVMe cannot reach
Backup target for other servers	Too small	Too small	No	Buy this	No	Write once, read rarely, keep for years. Spinning media is the correct tool and always has been
Your own hypervisor	Nested, slowly	From 32 cores up	No	No	Buy this	Nested virtualisation on someone else’s hypervisor is a compromise; metal removes the outer layer
Reselling virtual machines	No	Possible	No	No	Buy this	You need firmware, partitioning and the whole box, plus predictable behaviour for your own customers
Ninety-ninth percentile under strict budget	Good	Good	No	No	Best	Cache and interrupts cannot be partitioned cleanly, so single tenancy is the last few percent
Edge nodes in fifteen countries	Buy this	Twenty-seven sites	Eight sites	Eighteen sites	Nine sites	Ryzen is the only line in all thirty-four sites, which makes it the default for spreading out

Three questions that settle it

Almost every recommendation we give comes out of the same short interrogation. You can run it yourself in about ten minutes with a profiler and a calculator.

Answer these honestly and the table usually stops being necessary.

01
Where does the time go?
Look at a flame graph or a simple top under real load. One thread pinned at a hundred percent while the others idle means Ryzen. Forty threads all busy means EPYC. Everything waiting on disk means the storage line or more NVMe. Everything waiting on the GPU means you already knew the answer.
02
How big is the part that has to be in memory?
Resident set at peak, plus the page cache you genuinely benefit from. Under a hundred and twenty-eight gigabytes leaves you in the Ryzen line. Over it, the decision is made for you, and the EPYC tiers exist in the sizes they do for that reason.
03
What does an hour of downtime cost?
If the honest answer is “not much”, one machine is fine and metal is a reasonable indulgence. If it is a serious number, buy two smaller virtual instances in different cities instead of one large machine, and practise the failover before you need it.

If you would rather not do this alone, open a ticket describing the workload in two lines. You will get an answer with a median of eleven minutes, and occasionally that answer is that you should buy the cheaper thing.

The four mistakes we see weekly

Nobody makes these because they are careless. They come from sizing a machine against a plan rather than against a measurement.

Every one of these arrives in the ticket queue at least once a week.

Buying cores instead of clock

A forty-eight core instance running a single-threaded process is the most expensive way to be slow that we sell. Check the profile before the invoice; the fix is usually a smaller Ryzen instance that costs a third as much and finishes sooner.

Buying NVMe by the terabyte

Once you are past a couple of terabytes, the arithmetic favours a storage node with an NVMe tier in front of bulk capacity. People discover this after the second capacity upgrade rather than before the first.

Buying metal for a workload that fits

Single tenancy earns its money on tail latency and on control. If neither of those words appears in your requirements, a virtual instance with dedicated cores does the same job, deploys in under a minute and can be resized.

What every line shares

Whichever line you pick, the platform underneath behaves the same way. That is deliberate and it makes moving between lines a data problem rather than a re-learning exercise.

The differences are the silicon. Everything else is identical on purpose.

Dedicated resources

Cores are pinned, memory is reserved at boot, disk capacity is thick-provisioned. The overselling ratio is zero on every line, including the cheapest one.

The same network

Dedicated ports, unmetered under a published fair-use figure, with up to twelve terabits per second of edge scrubbing permanently in path. A routed IPv6 /64 is included everywhere.

The same panel and API

One place to build, snapshot, rebuild, resize and read your telemetry. Anything the panel can do, the API can do, because the panel is written against the API.

The same policy

Sign-up is an email address. Payment is crypto through OxaPay. There is no document request at any threshold, on any line, at any order value.

The same promises

99.99% contractual monthly uptime with automatic credits, a median first response of eleven minutes, and a seven-day refund with no reason required.

Changing your mind

Sizing is a guess until real traffic arrives. The sensible way to buy here is to guess small, measure, and move once you have numbers.

Cheaper for both of us than an argument in month four.

Within a line, moving up is usually a reboot: memory and NVMe grow in place while the node has room, and a jump the node cannot absorb becomes a live migration we schedule with you. Between lines it is a new instance and a copy, which is why we suggest keeping your build reproducible from the first day rather than the third month.

Term discounts run from five percent quarterly to thirty-five percent over two years. Buy monthly while you are still guessing. Commit for a year once the shape of the workload has stopped surprising you, and not before, because the discount is not large enough to justify locking in the wrong machine.

The first week is refundable

Seven days, no reason required, refunded in the asset you paid with. A serious test costs you attention rather than money.

Snapshots make experiments cheap

Take one before every change you are unsure about. Restores take seconds, which turns a risky upgrade into a reversible one.

Support will talk you down

Tell us what you are trying to run and we will tell you the cheapest line that does it. Selling somebody a machine they resent is a poor way to keep a customer for five years.

Ryzen NVMe

Highest single-core throughput

01 / 5

Price

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