The short answer, sorted by situation
There is no single right answer, but there is a right answer per situation, and it is usually decided by three facts about your connection rather than by price. Those facts are: whether you can get inbound traffic to your machine at all, how much upload you can spare, and whether the server needs to be online when your own computer is off.
Work through them in that order. If the answer to the first is no, the cost comparison never happens, and you are choosing between a tunnel and renting. If the answer to the third is no, the honest recommendation is to spend nothing at all: run a listen server or a dedicated server on one player's PC and connect over a mesh VPN. That covers a large share of the people who search this question, and no hosting company benefits from telling them so.
- Three to six friends playing in sessions: self-host on any PC in the group and join over Tailscale, ZeroTier or WireGuard. No port forwarding, no public exposure, no cost.
- Small always-on server, symmetric fibre, public IPv4, a machine you already leave running: self-hosting is genuinely cheaper. Budget four to eight hours of setup.
- Behind CGNAT, or upload under about 10 Mbit/s shared with work calls and streaming: rent, or accept a tunnel and its added latency.
- Public server that strangers can find and join: rent. A published home IP is a permanent target and your ISP's remedy is to null-route your whole household.
- Donations, income, or players in another timezone: rent. The uptime maths stops being a hobby problem.
What your upload actually has to carry
Game servers are upload-heavy and download-light. The server sends world state to every client and receives only small input packets back, so your traffic is roughly players multiplied by a per-player rate, in the direction consumer connections are weakest.
Rough planning figures per connected player, on the upstream: Minecraft Java sits around 80 to 150 kbit/s in steady play, with bursts into several Mbit/s when someone sprints into ungenerated chunks. Valheim and Rust are heavier than their small player counts suggest, roughly 150 to 400 kbit/s each. A Source-engine shooter at 64 tick lands around 200 to 400 kbit/s. Terraria and Project Zomboid are light, comfortably under 100 kbit/s.
Treat all of that as order-of-magnitude and then measure your own. Run the server for an evening and read the interface counters with iftop or nload on Linux, Resource Monitor on Windows, or your router's traffic graph. Multiply the measured peak by two for headroom, because the number that ruins a session is the burst, not the average.
- Minecraft Java 25565/TCP; Minecraft Bedrock 19132/UDP
- Rust 28015/UDP game, 28016/TCP RCON, 28082/TCP for the Rust+ companion app
- Valheim 2456-2457/UDP; Palworld 8211/UDP; Enshrouded 15636-15637/UDP
- CS2 and Garry's Mod 27015 on UDP and TCP; Terraria 7777/TCP; Satisfactory 7777 on UDP and TCP
- ARK: Survival Ascended 7777/UDP plus 27015/UDP for Steam queries; 7 Days to Die 26900/TCP plus 26900-26902/UDP; Project Zomboid 16261/UDP
Port forwarding, CGNAT, and the IP you cannot get
Port forwarding itself is five minutes of work: forward the game port to your machine's static LAN address and allow it through the host firewall. Windows Firewall silently blocking the inbound rule is the single most common reason a correctly forwarded server still looks offline.
CGNAT is the harder problem. Your ISP shares one public IPv4 across many subscribers, so there is no port for you to forward. Check in ninety seconds: compare your router's WAN address to what a what-is-my-IP site reports. If they differ, or the WAN address falls inside 100.64.0.0/10 (RFC 6598 shared space), you are behind CGNAT. A WAN address in 10.x or 192.168.x means double NAT, usually an ISP box in front of your own router.
Your options, in order of how well they work: ask the ISP for a public or static IPv4, which many sell for a few euros a month or bundle with a business tariff; use IPv6, which only works if every player also has IPv6, so it fails for anyone on mobile or an older provider; or tunnel out to a cheap VPS with WireGuard, or use a service like playit.gg. Tunnels work, but every packet takes a detour, adding 5 to 40 ms, and the tunnel's bandwidth becomes your ceiling.
- A CDN in front of your website does nothing for game traffic. HTTP proxying and raw TCP/UDP proxying are different products, and the raw-port ones are paid tiers — check the current pricing with the provider before planning around it.
- A dynamic IP that changes on the ISP's daily PPPoE reconnect will break every saved server entry. Use dynamic DNS with a low TTL on the A record.
- For Minecraft Java, an SRV record (_minecraft._tcp.yourdomain) lets you run on a non-standard port and still hand out a clean address with no port suffix.
- UPnP works until it does not. Set the forward manually so a router reboot cannot quietly drop it.
Your home IP becomes the server address
Every player who connects learns the IP of the server, and if you self-host that is the IP of your house. This is not theoretical. Banned players, rival clans and bored teenagers with booter subscriptions attack game servers routinely, and the tooling costs a few euros a month.
The failure mode is worse than most people expect. You do not need a large attack to take down a home line. A few hundred Mbit/s of UDP saturates most residential uplinks, and long before bandwidth becomes the limit, a consumer router falls over on packet rate: NAT connection tables on typical ISP hardware hold tens of thousands of entries and a flood fills them in seconds, taking every device in the house with it. Your provider's remedy is usually to null-route your address, so the household stays offline until the attack stops, including anyone working or studying from home. Most residential contracts also prohibit running public services, which weakens your position when you phone support.
There is a security dimension too. An exposed server sits on the same network as your personal machines unless you deliberately isolate it.
- Put the server on its own VLAN or guest network so a compromise cannot reach your NAS, your work laptop or your backups.
- Never expose RCON. Rust's 28016 and Minecraft's 25575 are scanned continuously. Firewall them to your own address or bind to localhost and reach them over SSH.
- Expect automated scanners to find a newly opened Minecraft port within hours and list it publicly. Enable whitelist and online-mode before you open the port, not after.
- Patch remote code execution bugs the same day. Log4Shell was exploitable through in-game chat on unpatched Java servers, and that class of bug recurs.
- A rented server sits behind the provider's filtering, and none of your household traffic shares the target.
What the electricity actually costs
Power is the cost self-hosters most consistently underestimate, because it is invisible and it arrives monthly.
The arithmetic is simple. Monthly cost in euros equals average watts multiplied by 0.72, multiplied by your price per kWh. The 0.72 is 24 hours times 30 days divided by 1000. Use your own tariff: EU household electricity in 2026 ranges from roughly €0.20 per kWh in Poland and the Baltics to around €0.38 in Finland.
Now the two realistic machines. A modern N100 or N150 mini PC with 16 GB of RAM draws 6 to 10 W idle and 15 to 25 W running a couple of game servers. At 18 W and €0.25 per kWh that is €3.24 a month. An old gaming tower repurposed as a server is a different animal: a six-core desktop with a discrete GPU still installed idles at 60 to 110 W and pulls 120 to 180 W under load. Call it 100 W average and it costs €18 a month at €0.25, or about €28 on German tariffs.
That last figure is the one that changes decisions. The free hardware is often the most expensive option.
- Measure rather than estimate. A plug-in energy meter costs around €15 and settles the argument in a day.
- A €220 mini PC amortised over 36 months is €6.10 a month before power.
- Pulling the discrete GPU and undervolting saves more electricity than any amount of software tuning.
- Add heat and noise. A tower running 24/7 in a bedroom is audible, and in summer you pay for it a second time through cooling.
- A small UPS (€80 to €120) that triggers a graceful shutdown is the cheapest insurance against a corrupted world file.
Uptime, in hours rather than nines
Percentages hide the shape of the problem, so convert them. 99.9% is 43 minutes of downtime a month. 99% is 7.2 hours. 95% is a day and a half.
A well-run home server realistically lands between 99% and 99.5%, so three to seven hours a month, once you count the things nobody plans for: scheduled ISP maintenance in the small hours, the forced 24-hour PPPoE reconnect many providers still do, Windows deciding to install updates and reboot, a summer thunderstorm, a router firmware update, and somebody unplugging the wrong thing during a tidy-up. None of that matters if your players are three friends in one timezone who play on Thursday evenings. It matters a great deal if you run a community across Europe and the server goes dark at 03:00.
Be sceptical of uptime claims in both directions. A hosted node removes your power cuts and your ISP but introduces someone else's. Where a provider states a figure, ask whether it is a target or a contractual SLA with credits attached. Puranode, for the record, targets 99.9% and does not sell service credits.
- Set Windows active hours and defer feature updates, or run the server on Linux where reboots happen when you decide.
- Automate backups off the machine. A world that exists only on the disk that failed was never backed up.
- Test the restore. Nobody discovers a broken backup at a convenient moment.
- If the server must be up while you sleep, make sure somebody else can restart it, or accept that it stays down until you wake.
CPU, not RAM, is what makes a server feel smooth
Most people diagnosing lag reach for more RAM, and most of the time that is the wrong lever.
The main simulation loop in Minecraft, Rust, Valheim, Project Zomboid and 7 Days to Die is largely single-threaded. A tick has to finish inside 50 ms, and when it does not, everyone feels it. That is a single-core throughput problem and no amount of extra memory fixes it. It is also why a Raspberry Pi 5 or an old NAS will happily run a small vanilla world and then collapse under a 120-mod pack, while a modern desktop CPU boosting past 4.5 GHz does roughly two to two and a half times the single-thread work of a 2015-era chip.
On memory specifically: a vanilla Minecraft server with eight players is comfortable in a 2 to 3 GB heap. Giving the JVM 12 GB does not make it faster and can make garbage collection pauses longer and more noticeable. Set -Xms and -Xmx to the same value, use G1GC with sensible flags, and spend the effort on view distance, entity limits and chunk pre-generation instead.
- Look at tick time first. In Minecraft use /tps or a profiler such as Spark. The answer is usually entity counts, hoppers, redstone or live chunk generation.
- Pre-generate the world. Most exploration lag is terrain generation happening on the main thread while players wait.
- Drop view and simulation distance before buying anything. Going from 12 chunks to 8 is often the single largest win available.
- More RAM helps exactly one thing: fitting a larger modpack's assets and loaded chunks in memory. If you are not swapping or hitting OutOfMemoryError, you do not need it.
Latency: work out who you are optimising for
Self-hosting gives you a 1 ms ping and gives everyone else the ping to your town, routed over consumer-grade paths. Hosting in a datacentre gives you 10 to 30 ms and gives everyone else a broadly similar figure, over transit and peering built for the job.
Approximate round-trip times to a central-European datacentre over fibre: Amsterdam and Berlin 5 to 12 ms, London and Paris 15 to 22 ms, Warsaw and Vilnius 20 to 30 ms, Stockholm 25 to 32 ms, Madrid and Rome 30 to 45 ms, Istanbul 50 to 65 ms, US East Coast 85 to 100 ms. A player's own last mile adds to all of that: typically 3 to 8 ms on fibre, 10 to 20 ms on VDSL, and 25 to 60 ms on 4G or 5G fixed wireless.
Jitter matters more than absolute ping for how a server feels, and a home line is where jitter comes from. One Steam download or a 4K stream saturates your upload and adds hundreds of milliseconds of buffer delay for everyone connected.
- Enable SQM or fq_codel/cake on the router and cap upload to about 90% of the measured rate. It is free and it is the biggest quality win available to a self-hoster.
- Test before you commit. Run ping and mtr from a friend's connection to your home IP across a full evening, not for ten seconds.
- Bufferbloat is measurable. Use a speed test that reports latency under load and read the latency grade, not the megabits.
- In a competitive shooter, hosting on a player's own machine gives that player a genuine advantage. Worth naming out loud in a clan.
The break-even, worked three ways
Assume a small always-on Minecraft or Valheim server for eight to ten people, run for a year.
Option A, reuse the old gaming tower you already own. Hardware €0. Power at 100 W average and €0.25 per kWh, €18 a month. A public or static IPv4 from the ISP if you need one, €0 to €5. Off-site backup storage, €1 to €2. Total roughly €19 to €25 a month, plus your time.
Option B, buy a low-power box. A 16 GB N150 mini PC with a 512 GB NVMe is around €220 in the EU, which is €6.10 a month across three years. Power at 18 W, €3.24. Same IP and backup line items. Total roughly €10 to €16 a month, and it is silent.
Option C, rent. A 4 GB Minecraft or Valheim plan at Puranode is €10.99 a month including VAT, with no hardware, no electricity, no port forwarding, DDoS filtering in front and automated backups.
So Option B genuinely competes and beats renting if you price your setup time at zero. Option A, the one that feels free, is the most expensive of the three.
- The line item people forget is time: four to eight hours of initial setup, then one or two hours a month for updates, mod version bumps and the occasional restore.
- If you enjoy that hour, it is not a cost. If you resent it, price it at whatever you earn and redo the sum.
- Add the value of not having your household internet null-routed if the server ever becomes a target.
- Renting has no residual value; a mini PC becomes a media server or a home lab node afterwards. Count that if you are being fair to Option B.
When self-hosting is plainly the right answer
Say it plainly: for a lot of people asking this question, the answer is that you do not need to buy anything.
If you and three friends want to play Valheim, Palworld, Enshrouded or Satisfactory together on Saturday afternoons, use the game's built-in co-op or run the dedicated server on one player's PC and connect everyone over a mesh VPN. That is free, needs no port forwarding, exposes nothing to the public internet, and takes about fifteen minutes. Renting for that is spending money to solve a problem you do not have.
Self-hosting is also right when the friction is the point. If you want to learn Linux, Docker, firewalls and DNS, a game server is an excellent excuse and a real one, because you will notice immediately when it breaks.
And it is right when you already have the infrastructure: an always-on home lab, symmetric fibre, a public IPv4, a UPS and a backup routine you actually test.
Renting earns its keep in one specific case: a server strangers can reach that has to be up when you are not. Everything else is a preference.
- Mesh VPN options: Tailscale, ZeroTier, or a self-run WireGuard mesh. All have free tiers that comfortably cover a group of friends.
- Session-only play is the strongest case for self-hosting. If nobody plays while the host is offline, a rented server is idle capacity you are paying for.
- Valheim, Palworld, Enshrouded and Satisfactory all have workable built-in co-op for small groups. Try that before standing up a dedicated server.
- Move to renting when you outgrow it: a public listing, a second timezone, or the first time a banned player threatens your connection.