Running a game server on Windows is mostly a problem of port discipline and session accounting, not raw CPU. A Minecraft Java server, a Rust dedicated server, and a CS2 instance all behave differently under load, but each one fails in a predictable order: first the tick rate slips, then the player count caps out below the advertised slot count, then the network layer becomes the bottleneck. This article walks through the specific firewall rules, service configuration, and measurement steps that keep a Windows-hosted game server responsive.
Why Windows for a Game Server
Most game server software ships Linux binaries first, so the honest answer is that Windows is the right pick when the server is part of a broader Windows estate: the same box also runs the community’s IIS front-end, the Discord bot, the admin panel, and a small SQL Server database. It is also the right pick when the operator is a Windows administrator who can secure and patch a Windows host properly, and the wrong one for someone who has never configured a Linux firewall either. The performance delta on modern CPUs is smaller than the operational delta.
What matters far more than the OS is the shape of the instance: single-thread clock speed for the tick loop, enough RAM for the working set plus JIT and OS, and a low-jitter network path. A 4 vCPU / 8 GB instance beats an 8 vCPU / 8 GB one for most small game servers, because the tick loop is single-threaded and per-core clock is the limit.
Port Map by Game and the Rules That Follow
| Game | Protocol | Ports | Notes |
|---|---|---|---|
| Minecraft Java | TCP | 25565 | Also 25575 for RCON (bind to localhost) |
| Minecraft Bedrock | UDP | 19132 | UDP only; common firewall miss |
| Rust | UDP | 28015 (game), 28016 (RCON/Web) | RCON must not be public |
| ARK: Survival | UDP | 7777, 7778 (raw), 27015 (query) | Query port must be reachable |
| CS2 / Source | UDP | 27015 (game), 27020 (SourceTV) | TCP 27015 for RCON only |
The rule shape is the same every time: an inbound allow for the public game port on the Public profile, and an explicit deny for the admin port on any interface except loopback or a management subnet. Windows Defender Firewall’s default inbound policy is block, which is good — but it is common to find a port range “temporarily” opened and never closed.
Create rules by name so they are auditable later:
New-NetFirewallRule -DisplayName "Minecraft-25565-In" -Direction Inbound -Protocol TCP -LocalPort 25565 -Action Allow -Profile Public
Then confirm from outside the host, not from the host itself. A rule that works from localhost proves nothing. Use an external port checker or a second VPS to test the actual path through the provider’s edge firewall, which is a separate layer from Windows Firewall and commonly the one that is blocking.
Running the Server as a Service, Not a Console Window
Running the game server inside an RDP session means it dies when the session disconnects or the admin logs off. The correct pattern on Windows is a proper service or, for Java-based servers, a wrapper that supervises the process. Two workable options: NSSM (Non-Sucking Service Manager) to run the JVM or the game binary as a Windows service, or a scheduled task configured to run at system startup under a dedicated service account with “run whether user is logged on or not”.
Either way, use a dedicated local account with a strong non-expiring password, granted “Log on as a service” and nothing else. Do not run game servers as LocalSystem — it is third-party code updated frequently and has no business holding SYSTEM rights.
For Java servers, set the heap explicitly and leave headroom for the OS: on an 8 GB instance, -Xms4G -Xmx4G for a modded server is a reasonable ceiling, with 2 GB left to the OS and file cache. Oversizing the heap is a classic mistake — a bigger heap means longer major GC pauses, which manifest exactly as the tick-rate spikes you were trying to avoid.
Measuring Tick Rate and Player Capacity
Every popular game server exposes a tick-rate signal, and reading it beats guessing. Minecraft reports TPS in its console and via /tps; Rust and CS2 report tick and server FPS; ARK reports similar counters. Watch the worst window, not the average: 19.9 TPS with regular drops to 12 is worse than a steady 18.
On the host side, the counters that correlate with tick problems are CPU time per core (not total), context switches per second, and disk queue length on the world-save volume. A world save that blocks the main thread for 400 ms produces a visible rubber-band for every player; moving the save to a separate volume or enabling async saving where the server supports it often fixes it without touching CPU at all.
Slot caps are usually set by memory and per-player overhead, not by the advertised maximum. Measure by loading the server incrementally and watching both TPS and working set. If working set grows steadily with no plateau and the server is Java-based, suspect a leak or an unbounded world-border strategy before buying more RAM.
Network: Bandwidth, Jitter, and DDoS Reality
Bandwidth rarely binds for a small game server; jitter and packet loss do. A 100-player CS2 server at 64 tick moves a few Mbps but is extremely sensitive to 20–30 ms of jitter. Test from a real client at the player’s location, not datacentre-to-datacentre — the last mile is where jitter lives.
DDoS deserves a blunt assessment: a VPS provider without network-level mitigation will null-route your IP when an attack arrives, and no amount of Windows configuration prevents that. What you can do is reduce the blast radius. Bind RCON and web consoles to loopback, put the admin panel behind a VPN, and enable Windows Firewall rate limiting via the “Advanced Security” settings for the game port if your provider’s edge does not already do it. If you expect attention, choose a provider with an anycast scrubbing network, and test the mitigation before you need it by asking support how null-routing is triggered.
Maintenance: Backups, Updates, and Restart Windows
Three routines keep a game server healthy. First, an automated world backup on a schedule that runs while the server is empty — a simple PowerShell job that triggers a save, waits, and copies the world directory with Robocopy /MIR to a separate volume or off-host bucket. Second, a settled update schedule: game server software updates break mods and plugins, so stage them, read the changelog, and restart in a known-empty window rather than auto-updating. Third, an OS patch window that does not collide with peak play hours, with reboots rehearsed so the service comes back automatically.
Document the restart procedure. On Windows the clean path is Restart-Service on the wrapper service, followed by a TPS check and a connectivity test from outside. If the server needs a world save before shutdown, build that into the service’s stop logic or a pre-restart script; a hard kill during a save is how worlds get corrupted. If you would rather not operate that layer yourself, a discussion with the hosting team about your game server requirements is usually more productive than tuning blind.
A Starting Configuration That Holds Up
- 4 vCPU / 8 GB for a 20–40 player Minecraft or Rust server; 2 vCPU / 4 GB is enough for a small friends-only instance.
- NVMe storage for the world volume; saves are latency-sensitive writes.
- Game port open on the Public profile only; RCON and admin web bound to loopback.
- Dedicated local service account, “Log on as a service” only, no LocalSystem.
- Explicit heap ceiling for Java servers, leaving 2 GB to the OS.
- Nightly world backup to a separate volume, tested by restoring once.
- External connectivity test after every restart, not just a localhost check.
None of this is exotic. The failures that take game servers down on Windows are almost always the boring ones: a UDP rule missing, a server running in an RDP session, a heap that is too large, a backup never restored, or a provider that null-routes under attack. Getting those five right puts you ahead of most hobbyist deployments. When you are ready to compare instance shapes and network options for the workload, the Windows VPS hosting overview covers the plan-level differences.
