Valve's official CS2 dedicated server documentation maintained on the Valve Developer Community wiki, offers an operator-facing window into the infrastructure decisions behind one of Steam's most-played competitive games. Published alongside the game's launch in September 2023, it is written for server administrators, not engineers. But read carefully, it reveals deliberate architectural choices that any multiplayer developer can learn from.

A second thread runs through Valve's work on anti-cheat. Engineer John McDonald's 2018 GDC talk on VACNet, which we covered previously in our CS:GO anti-cheat deep dive, remains directly relevant to CS2, where the system has continued to evolve. Both threads are worth reading on to help multiplayer game developers assess their own architecture decisions.

Merging Client and Server

The most immediately notable detail in the documentation is one that looks routine: the CS2 dedicated server and game client now share the same Steam App ID. In CS:GO, the client was appid 730 and the dedicated server was appid 740. Two separate downloads, two update pipelines, two surfaces for version drift. In CS2, both live under appid 730.

That consolidation simplifies meaningful operational work. Server operators maintain one installation. Update scripts target one ID. Community documentation converges rather than splits. For teams running fleets of instances, removing one divergent dependency is a genuine quality-of-life gain.

The trade-off is visible right there in the same documentation: the server image now carries client-only assets it will never use. A CS2 server download weighs approximately 60 GB as a result. That's a real infrastructure cost, particularly for studios spinning up many instances simultaneously.

Valve chose operational simplicity over storage efficiency, and the documentation doesn't hide the downside. That kind of honest trade-off acknowledgment is worth modeling.

Container-First Hosting

CS2 arrived with first-party Docker support at launch. The documentation shows a one-command setup: a single docker run call that pulls the image, binds the required ports, and automatically updates the server on container restart whenever Valve ships a patch. No manual update scripts. No version mismatches between a stale binary and a live game.

The community moved quickly on top of that foundation. Within weeks of launch, projects like CS2 Pterodactyl had built direct integration with the open-source game panel that many community operators already use. That speed of adoption reflects something deliberate in Valve's approach: publishing clear, stable documentation and supporting standard tooling is itself an infrastructure decision. Valve did the documentation work once. The ecosystem built on it was created by others.

For developers evaluating whether to invest in Docker and container-native server design early, CS2's trajectory is a useful reference point. The upfront documentation investment compounds over time.

Sub-Tick: Decoupling Precision from Tick Frequency

The documentation points toward CS2's sub-tick architecture without explaining it in depth. It warrants its own article, and Valve's official launch video "Moving Beyond Tick Rate" will be the primary source for that piece. But the core idea is worth briefly establishing here.

In CS:GO, as in most competitive shooters, every player action was processed at the server's tick boundary. At 64 Hz, ticks arrive every 15.6 ms. If you fired 1 ms before a tick boundary, the server treated that shot as if it happened 14.6 ms later. Competitive platforms like FACEIT ran 128 Hz servers specifically to halve that gap, which is why the community cared about tick rate so deeply.

CS2's sub-tick system sidesteps the problem differently. Every client input now carries an exact timestamp. The server receives those timestamps and reconstructs a precise ordering of events regardless of where within the tick they fell. Tick rate becomes less important as a proxy for input accuracy — in theory.

In practice, the community debate since launch has been more complicated. Some professional players, including FaZe's Robin "ropz" Kool, have noted that the subjective feel still doesn't fully match 128 Hz CS:GO to an experienced player. That gap between technical correctness and perceived responsiveness is itself a useful developer insight: players' perception of latency is not the same thing as measured latency. More on this in a future piece.

Anti-Cheat as a Learning System

The server documentation is focused on setup and configuration, so it says little about anti-cheat directly. But no discussion of CS2's backend is complete without it.

VACNet, originally built for CS:GO and now running in CS2 as VAC Live, was designed as a continuous learning loop. John McDonald, who presented the system at GDC in 2018, described the central insight as recognizing that CS:GO's Overwatch peer-review system had been quietly generating labeled training data for years before anyone thought to use it. "Before building a pipeline," McDonald noted, "audit what labeled data you already have."

The architecture's key design decision was keeping humans in the verdict loop. VACNet doesn't ban players. It submits high-confidence cases to human Overwatch jurors, who review and decide. Those verdicts feed back into the next retraining run. A cheat developer who learns exactly what patterns the model watches for, and adapts their tool accordingly, will still face a human juror who recognizes cheating when they see it. That verdict becomes new training data. The system grows from each attack rather than being invalidated by it.

Since CS2's launch, the system has gained real-time detection capability. The original VACNet flagged players after a match concluded for post-hoc review. VAC Live can now cancel a match mid-game the moment a cheater is detected. That shift from batch analysis to live inference was exactly the direction McDonald identified as "ongoing work" at the end of his 2018 talk. The loop is still running. It just runs in real time now.

The full architecture breakdown, including the data pipeline, the Trust Score system, and the design principles behind keeping humans in the final call, is covered in our CS:GO anti-cheat deep dive.

Community Servers and the Hosting Question

Valve has allowed players to run their own Counter-Strike servers since CS 1.6. That continuity is not an accident. Community servers have been central to Counter-Strike's longevity: custom maps, aim-training servers, surf and KZ communities, and the competitive infrastructure that eventually grew into FACEIT and ESEA. That ecosystem was built on top of a hosting model Valve made possible and documented clearly.

For Valve specifically, open hosting is a trade-off they can afford. Revenue from server hosting flows to community operators, not to Valve. In exchange, Valve gets an ecosystem that sustains player interest, competitive play, and the kind of long-term engagement that supports a 25-year-old franchise.

For a studio without Steam's platform beneath it, the calculation looks different. Community hosting is a cost center to someone; the question is who bears it. Studios can build dedicated server resale into their model — offering hosted private servers as a product line alongside cosmetics or season passes. Container-as-a-service infrastructure makes this more practical than it was even a few years ago. Platforms like Edgegap's game server orchestration let studios offer that kind of resale without building the hosting stack themselves, turning what is traditionally a pure cost into a potential revenue stream.

The decision to open up hosting should follow from what the community actually needs and what the studio can sustain. Valve's history is instructive. But it's a history built on specific advantages that don't transfer automatically.

—

This article is based on and cites Valve's official CS2 Dedicated Server documentation, published on the Valve Developer Community wiki, alongside insights from John McDonald's GDC 2018 talk on VACNet, available on the GDC YouTube channel.

All rights in the original content are owned by their respective owners.