Renting turns hardware into a monthly line item; colocating turns it back into an asset with jobs attached. The technical difference is small, the financial one decides everything. Build both sides over three years — and cost your own engineer's time honestly.
Colocation vs dedicated servers is a capital question wearing an infrastructure costume. Renting a machine converts hardware into a monthly line item and hands the operational risk to someone else. Colocating converts it back into an asset you own, a depreciation schedule and a set of jobs that are now yours. The technical difference is small. The financial and organisational difference is the entire decision, and there is a breakeven point you can calculate rather than argue about.
A rented dedicated server is hardware, rack space, power, cooling, IP transit, IPMI access, drive replacement and a support contract, bundled into one price. When a disk dies, someone else swaps it.
Colocation is space, power and connectivity. You provide the servers, the spares, the configuration, and the person who decides what happens when a power supply fails at 4am. Remote hands exist and are billed by the incident or included by contract; either way, someone has to know what to ask for.
Everything else — network quality, uptime, physical security — comes from the facility, not from which product you bought. That is why the comparison is financial rather than technical.
Build both sides over the same three-year window.
Rented, from our published entry prices: an entry 1 Gbps build at €209/month is €7,524 over 36 months. A 10 Gbps build at €659/month is €23,724.
Colocated, per machine:
hardware capex ÷ 36
+ rack space share (price per U or per rack ÷ machines)
+ power (draw × facility rate)
+ transit (committed rate or unmetered port)
+ spares (~10% of capex, amortised)
+ remote hands (incidents × rate)
+ your own time (the line everyone leaves out)
Colocation is quoted per rack and per kilowatt rather than per server, so the per-machine cost falls as you fill the rack. That is the whole shape of the answer: colocation wins on density, not on the first server. One machine in a rack is always more expensive colocated. Twenty machines in the same rack usually are not.
Three inputs move the breakeven more than the rest:
Power draw, measured not assumed. A dual-socket box with 24 NVMe drives is not a 300 W machine. Facilities bill on committed kilowatts, and buying too little power means you cannot fill the rack you are paying for.
Refresh cycle. Hardware you own has a useful life; when it ends you either buy again or run equipment past its warranty. Renting moves that problem to the provider and prices it in. If you plan a 5-year life, the comparison changes materially against a 3-year one.
Your own labour. An hour a week of engineer time on hardware is roughly a hundred hours over three years. Cost it honestly and it moves the breakeven by several machines.
Colocation wins when:
Renting wins when:
The honest summary: under ten machines, rent; over a rack, colocate; between the two, the labour line decides it.
Four line items exist in a colocation budget and nowhere in a rental invoice, and they are the ones spreadsheets miss:
Spares held on site. A drive that fails at 2am is only a small problem if a replacement is already in the cage. Shipping one is a two-day outage. Plan on roughly 10% of drive count and one spare power supply per chassis model.
Cross-connects. Every link out of your rack — to transit, to a peer, to another cage — is a billable circuit with a setup fee and a monthly. Two or three of them changes the per-machine arithmetic on a small footprint.
IP transit commitment. Colocation transit is usually sold as a committed rate with overage, not as an unmetered guarantee. Commit too low and you pay overage; too high and you pay for capacity you never touch.
Travel. Somebody occasionally has to be in the building. If the facility is a flight away, that is a real number, and it is the argument for buying remote hands as a contract rather than per incident.
None of these is large on its own. Together, on a footprint of five or six machines, they are frequently the difference that keeps renting ahead.
The interesting answer is usually both. Colocate the stable core — the storage nodes, the databases, the machines whose shape has not changed in two years. Rent the edges: burst capacity, new regions, anything experimental, anything you might turn off.
That split works because the two products fail differently. Owned hardware in a rack is cheap and slow to change. Rented hardware is more expensive per month and can be cancelled at the end of it. Matching each workload to the right one is worth more than optimising either in isolation.
The one thing to get right before shipping anything is the facility side. Colocation space is sold by the U, the rack or the cage, and the details that cause problems on install day — chassis depth against cabinet depth, continuous load against breaker rating, whether A and B feeds each carry the whole rack alone, IPMI addressed and tested before the pallet leaves — are all cheaper to fix beforehand. The colocation checklist is the pre-flight for exactly that.
If the answers point at a rack, get a colocation quote and price it against the rented equivalent using the formula above. If they point at four machines, rent them and revisit in a year — the arithmetic will still be there.
Is colocation vs dedicated servers really about cost? Cost is the largest term, but control is the tiebreaker. Colocation is the only option if you need specific hardware or physical custody of the equipment, whatever the spreadsheet says.
How many servers before colocation makes sense? Around ten as a rough marker, and a rack as a confident one. Below that, the fixed costs — space minimum, power commitment, spares, hands — divide across too few machines.
Can I colocate hardware I bought elsewhere? Yes. That is the normal case. Check depth, weight, power draw and rail compatibility against the cabinet before shipping.
What about network quality — is one better than the other? No. Both sit on the same backbone in the same facilities. Transit terms differ: rented servers include an unmetered guaranteed rate, colocation is quoted as a port with either unmetered or committed-rate transit.
Can I mix the two? Yes, and most growing infrastructure does. Colocate the stable core, rent the edges and the experiments.
One exit node is easy to specify and tells you nothing about the next fifty. Concurrency, throughput per session and oversubscription set subscribers per node; packet rate rather than cipher choice sets the ceiling; and country coverage wants a tiered fleet, not identical boxes.
No one can quote a player count without knowing the title, but the shape of the limit is knowable. The tick deadline binds first, memory decides instances per box, and bandwidth binds the fleet rather than the instance. Each has arithmetic you can run on your own numbers.
A shared slot and a dedicated node can cost the same per terabyte and behave nothing alike. Contended random IO, fair-use ceilings and shared address reputation are what separate them — along with everything a slot simply cannot run.