DDoS-Protected VPS for Game Servers — Minecraft, CS2, Rust

Tick math, heap sizing and UDP flood reality for Minecraft, CS2 and Rust — L3/L4 included on every plan; Warden is $19.00/mo.

Published 2026-08-30 · Updated 2026-10-14 · FYRHost Editorial · 17 min read

Sizing by RAM, clock, disk — in that order

The instinct when sizing a game server is to count cores first, and that instinct loses matches. A game world is not a web farm: the simulation runs as one hot loop inside a single server process, so what you are actually buying is a memory floor for the heap, one fast thread for the tick, and a disk that absorbs a world save without stalling the loop. Extra cores earn their keep only when several instances stack on one box.

The mechanism per game differs in where the pressure lands. Minecraft is a heap problem: the main thread advances the world 20 times per second — a 50-millisecond budget per tick — while chunk loading, entity AI and block entities all compete for JVM memory. CS2 is tick-rate bound, executing one simulation step every 15.6 milliseconds on a 64-tick server, where a single slow core misses deadlines no core count repairs retroactively. Rust sits between: 16 GB or more for a populated world, plus a save that serializes thousands of entities on a timer.

Where sizing breaks is the order of operations: people pick the plan, then ship a modpack, then discover the arithmetic was never done. Count the working set first — vanilla modest, modded communities at 8 GB realistic minimum and climbing — then match the tier. That is why the catalog ladder grows RAM faster than it grows vCPU count, and why the 16 GB tier is where most real communities land rather than at the bottom.

The second break is the multi-core fantasy: buying 12 mid-tier threads to solve what is a single-thread clock problem, or a heap problem, or a disk problem — never a thread-count problem. One strong core carries the tick; the rest of the plan exists for the heap, the save and everything else you stack beside the game. Size in that order and the plan stops being a guess.

Each game taxes a different part of that order, so the next three sections take them one at a time — heap first, then tick rate, then save cadence — because the plan that fits Minecraft is not automatically the plan that fits CS2, and the arithmetic differs in instructive ways.

Minecraft: a heap problem wearing a server costume

The JVM makes Minecraft's sizing honest in a way other games are not: the heap number is visible, and the plan must hold it plus the operating system's share. Pick Warden at $19.00/mo list — 6 vCPU and 16 GB of DDR5 — as the comfortable floor for a modded community, with 24 GB on Vanguard for heavyweight packs. Vanilla stays polite inside 4 GB; a modpack does not, and no plugin compresses a 12 GB working set into a smaller plan.

The mechanism is tick pressure meeting garbage collection. The main thread advances the world on a 50-millisecond budget, and when the collector pauses inside that budget, every player feels the world hiccup at once. Paper or Purpur improves both halves — better collectors, async chunk work — per the project's documentation, and the official server download at minecraft.net remains the vanilla baseline. Memory bandwidth and single-thread clock decide how much of the budget survives each pause.

Where Minecraft sizing breaks is the classic -Xmx error: setting the heap equal to the whole plan leaves the kernel no page cache, and every GC cycle becomes a disk event. On a 16 GB plan, run java -Xmx12G and leave the rest to the operating system; the collector needs headroom outside the heap too. The second error is blaming hardware for chunk lag that view-distance=8 in server.properties fixes for free — tuning before upgrading, always.

The third break is stacking: one box, three communities, one heap — and the first modpack that grows reclaims the memory its neighbors were promised. Set explicit limits per instance, watch free -m during evening peaks, and let the plan's total be the sum of promises you can keep. A 32 GB tier stacked carefully beats a 16 GB tier stacked hopefully, every weekend without exception.

Heap arithmetic settled, the next game inverts the problem: CS2 does not want memory so much as it wants one reliable deadline, met 64 times a second — and the way a plan delivers deadlines is different from the way it delivers gigabytes.

CS2 and Rust: deadlines and save cadence

CS2's arithmetic is a stopwatch: a 64-tick server executes one simulation step every 15.6 milliseconds, and subtick timing tries to repair the gaps between steps — but a single slow core misses deadlines that no amount of extra threads repairs retroactively. This is why a strong single-thread clock buys more fair fights than a dozen mid-tier cores, and why the high-clock tiers in the ladder are not a luxury for this workload.

The build itself comes from Valve's own tooling: SteamCMD installs the dedicated server, and the same pattern holds across Source titles. Rust splits the difference with Minecraft — a populated server wants 16 GB or more, and the world save serializes thousands of entities to disk on a timer, so write stalls read as rubber-banding for every player simultaneously. The official Rust wiki documents the save cadence if you want to plan snapshot windows around it.

Where both break is storage that averages well and stalls locally: a network volume with decent throughput still shows latency spikes exactly when the save timer fires, and those spikes are the rubber-band moments. Local NVMe — standard on every plan here — absorbs the saves because the latency tail is short, not because the headline throughput is high. The save window is the one moment a disk's worst case matters more than its average.

The second break is combining workloads that fight for the tick thread: a busy Rust server sharing a core with a database, or a CS2 instance whose neighbors burst at the same prime-time hour. Pin instances to cores, stagger save timers so they do not collide, and when the stacking stops being polite, split boxes rather than hoping — the tick thread does not negotiate, it just misses deadlines and players log the symptom as lag.

Sizing, then, is three numbers per game — heap, deadline, save — and the plan that satisfies all three for your community is knowable before you buy. What is not knowable in advance is the traffic you did not invite, which every public game IP collects within hours, and that is where the arithmetic gets adversarial.

The attack reality on a public game IP

The attack that kills a community server is usually not a cinematic 400 Gbps wall — it is a cheap UDP flood aimed at the game port, rented for a few dollars or fired from a free booter app, launched by someone who found port 25565 or 27015 during an ordinary range scan. Public game IPs get hit by three groups in practice: rival servers poaching players, bored booter subscribers, and scanners that fingerprint every open UDP port within hours of the IP going live.

The arrivals sort into three layers. Volumetric L3 floods try to saturate the uplink with garbage that pretends to be nothing; L4 floods — SYN storms on TCP, UDP packet storms on game and query ports — try to exhaust kernel state rather than wire; and application-layer abuse arrives dressed as legitimate players: login retries, query spam, chat floods. A rival does not need to out-engineer you; they need one layer to be cheaper than your patience, which is why plan for the cheap and constant.

Where expectations break is the third layer: operators read a protection badge and assume polite-looking abuse is covered too. It is not, and physics will not change it — a packet that looks exactly like a player login cannot be dropped without dropping players. Platform filtering handles the volumetric and state-exhaustion layers permanently; the behavioral layer is plugin and configuration territory, from login-rate limits in the engine to vote-reward throttling and chat moderation bots.

The UDP guideline the IETF publishes explains why game protocols sit awkwardly here: UDP services answer anyone, so amplification and reflection love them, and the defense is answering only what completes a handshake or a token. Engines with ticket-based query auth fare better than open query protocols — know which yours is before the first flood, not during it.

Three layers, three owners: the platform owns the first two, you own the third. What the platform's half actually promises — and the specific boundary where its job ends — is worth stating precisely, because the badge on the hosting page and the reality of a bad evening differ in exactly one layer.

What built-in filtering does — and what it never will

The counter-intuitive part of protection included by default is what it does not promise: it does not promise the application cannot be knocked over politely. It promises a floor — L3/L4 filtering upstream of your instance absorbs the volumetric and state-exhaustion classes before they reach the virtual NIC, so the cheap attacks die without a ticket. On this platform that floor rides every VPS SKU, and the filtering guide walks the layer boundary in full.

The mechanism has two halves worth knowing as an operator. Stateless filters at the edge drop malformed packets and blunt floods aimed at the wire; stateful tracking closer to the host counts flows per source and rate-limits the greedy, which protects the kernel's connection table. The result reads boringly well in practice: a multi-gigabit UDP storm lands as a brief graph spike while ss -s on your side stays flat and players never notice a frame. Boring is the deliverable.

Where the floor breaks is game-shaped floods at plausible rates — thousands of sources sending packets that could be players to port 27015. A filter dropping all of that would end the server as surely as the flood, so the platform passes what plausibly belongs to the game and the remainder is yours: hashlimit rules on the query port, aggressive login-rate limits in the game config, query cooldowns where the engine supports them. Order a Bastion at $108.50/mo when several communities stack on one box — 32 cores and 128 GB keep the instances and their defenses apart with room to spare.

The failure mode to avoid is tuning those limits from a cold start: caps set tight on day one, a normal evening arrives, and real players behind carrier-grade NAT get rate-limited into the same bucket as the flood. Set limits loose, baseline a week of real traffic, then tighten to a multiple of observed peaks — the same discipline every rate-based defense wants, and the one skipped most often.

Included filtering changes who answers the volumetric part — the fabric, automatically, instead of you at 3 a.m. — and it does not change who answers the behavioral part, which no per-IP upsell anywhere changes either. That is why the filtering belongs in the SKU rather than the checkout. Between floods, though, the tick loop has quieter enemies, and the next one is the disk.

Uptime, ticks and the disk's worst case

Players describe disk problems as lag, and they are right by mechanism: when the world save serializes on its timer, a write stall freezes the loop that owes everyone a tick in 50 milliseconds, and the whole room rubber-bands together. The save is non-negotiable — it is the world's insurance policy — so the question is which storage makes its worst case boring, and local NVMe's short latency tail is the reason it is on every plan here.

The mechanism worth knowing is the collision: the engine's save timer and your own snapshot or backup schedule land on the same minute, and two bulk writes queue behind each other at the worst possible moment. Stagger them deliberately — saves on the engine's cadence, snapshots on an offset hour — and the disk never sees the combined burst. Watch iostat -x 1 through one save cycle; the await column during the window tells you more than any benchmark.

Where this breaks is the restore path nobody rehearsed: a corrupted world at prime time, a snapshot from 40 minutes ago, and a restore procedure being read for the first time while the community watches the status channel. Rehearse the restore into a scratch directory monthly — file-level copies of the world folder plus the plan snapshots — and the worst evening becomes a 10-minute footnote instead of a lost community.

The second break is log and mod bloat: a year of logs, old mod versions and duplicate world copies quietly fill the disk, and the first symptom is a save that cannot complete because the filesystem is full — at prime time, naturally. A weekly du -sh pass over the server directories catches the drift while it is still a cleanup, not an outage, and keeps the NVMe's capacity available for the saves it exists to absorb.

Loop fed, saves boring, restores rehearsed — the remaining exposure is administrative: the panel that controls all of it, and who can reach it. Game panels are the most public admin surface in hosting, which is exactly why they get their own section next.

Admin surfaces and the quiet twin

A game panel is an admin dashboard wearing a public face: registration open to players, a login form indexed by scanners, and permissions that can restart or wipe every instance. The baseline is unglamorous — the panel behind HTTPS, admin accounts on 2FA, player accounts separated from management roles — and the hardening checklist supplies the machine-level half that panels never cover: keys, firewall, patches, restores.

The mechanism of a quiet admin path is separation: the panel's management endpoints bound to localhost or a private interface, with your own access through an SSH tunnel — or, for a path no scanner can enumerate at all, a hidden service that publishes no public coordinate. Players keep the public panel for registration and status; administration moves to the twin. The two audiences never need the same door, and merging them is how credential attacks reach the restart button.

Where admin hygiene breaks is the forgotten third-party plugin: a web wrapper, a stats dashboard, a donation bot with its own HTTP endpoint on an odd port — each one a public door added without a firewall decision. The rule is the same as everywhere: every listener gets a decision, and anything answering publicly that you cannot name in one sentence is a finding. ss -tlnp weekly keeps the inventory honest.

The second break is shared credentials across communities: one owner account managing several servers, logged in from a stream overlay, a phone and a cybercafe. Per-human accounts with per-instance permissions keep one compromised login from being every server's problem, and the audit trail starts meaning something — after an incident, whose action did what is the first question, and shared logins answer it with silence.

Admin path quiet, the last decisions are placement and payment: where the box sits relative to the players whose milliseconds pay the bills, and how the box gets paid for without the checkout becoming its own project. Both are shorter decisions than people expect, and they close the loop.

Placement and the no-KYC checkout

Placement for a game server is a latency decision, not an ideology decision: players vote with milliseconds, and a tick-based game degrades gracefully right up until it does not. The map spans 40 cities, so pick the rack near the players rather than near the operator — a community's center of gravity, not its owner's flag, decides the placement. Jurisdiction preferences still fit: Iceland and Norway carry a 20 percent premium, Switzerland 35 percent, Luxembourg, Cyprus and Panama 15 percent, list elsewhere.

The checkout itself stays out of the way: signup is an inbox plus a 12-character password or a bare token, no identity documents, and the box boots about 60 seconds after the crypto invoice credits. Payment clears in the coin you already use — BTC with 2 confirmations in 10 to 60 minutes, XMR after 10 blocks, TRC-20 USDT at 19 blocks and often 1 to 3 minutes in practice — so a server that must be up for a scheduled event tonight is a same-evening build, not a procurement cycle.

Where placement breaks is the measured-versus-assumed gap: owners place by rumor about regions, then discover the community's actual player distribution differs. Baseline honestly — have 5 regulars from different regions run a traceroute or read their in-game ping before the plan is chosen — and re-check after a season, because communities migrate. The 1 to 10 Gbps uplink ladder matters for packed servers; for most, the location pick moves player experience more than any other single choice.

The second break is payment-flow friction at renewal: a coin that stopped being convenient, an invoice that lapses during a busy week, a community scrambling because the box powered off. Automate the renewal habit the same way the snapshots are automated — a calendar entry with the funding step spelled out — because the platform's one-company, one-checkout model removes the onboarding friction but cannot remind you to fund the wallet.

That closes the loop from sizing to settlement. The final section compresses everything into the order you would actually run it — plan, doors, build, defenses, drills — so the checklist fits on one evening and the community notices nothing except better ping.

The game server, in the order to run it

Start at the account — inbox plus a 12-character password or a bare token — fund it in one of 19 coins, and pick the rack by player latency, not by flag; the box is up about 60 seconds after the credit posts. Size by the game's arithmetic: Minecraft wants the heap floor — 16 GB is the comfortable modded point — CS2 wants the strong single-thread clock, Rust wants 16 GB plus the short-latency NVMe that absorbs world saves.

Second, draw the doors: default-deny firewall, then the game and query ports opened — 25565 for Minecraft, 27015 for CS2's query side — admin surfaces bound to localhost or reached through a tunnel, and every listener accounted for by name. Third, build from the official tooling: SteamCMD for Source titles, the vendor download for Minecraft, with the JVM's -Xmx set to leave the kernel 4 GB on a 16 GB plan.

Fourth, set the behavioral defenses while the community is small: login-rate limits in the engine, hashlimit caps on the query port, chat and vote-reward throttling — tuned loose, baselined against a real week, then tightened to a multiple of observed peaks. Fifth, schedule the disk rhythm: engine saves on their cadence, snapshots offset from them, logs rotated, and the restore rehearsed into a scratch directory so the corrupt-world evening is a footnote.

Sixth, quiet the admin path: panel on 2FA, per-human accounts, management behind the tunnel or the hidden twin, and the weekly ss -tlnp glance that catches the forgotten endpoint. Seventh, after a season, re-measure placement against the community's actual geography and migrate calmly if the center of gravity moved. Run in that order, the server's bad evenings become the scheduled kind — snapshots, not floods — and the players notice only the ping.