How to set up a CS2 server: 64 tick, latency and multiple instances

This guide builds a working Counter-Strike 2 community server from scratch: choosing the operating system, installing through SteamCMD, setting a GSLT, opening ports and running several server instances on one machine. What sets CS2 apart from the other games on this list is its resource profile: RAM needs are small, and what decides quality is the CPU work done per tick and the player's latency.

Before you start: what you need

• A server. A single 10-12 slot server runs on 2 GB of RAM, 1 vCPU and 40 GB of storage. That is a small ask among game servers, so the budget is better spent on processor quality than on RAM. To pick resources one by one and see the monthly total: server configurator
• A GSLT (Game Server Login Token). Without this Steam-issued token your server will not appear in the public server list. Each instance you run needs its own token.
• A location decision. In a shooter a 20 ms difference is felt directly, and for players in Türkiye a domestic location saves tens of milliseconds over hosting abroad. No hardware upgrade closes that gap: server location and ping

1. Operating system

Choose Ubuntu 22.04 LTS. SteamCMD-based installs run with the fewest surprises on this distribution.

SteamCMD needs 32-bit libraries. Without the distribution's 32-bit compatibility packages, the very first command fails with a "file not found" style error whose cause is not obvious at all. Handle this as step one.

Do not run the server as root; create a separate user that exists only for the game. SteamCMD already refuses to run under root, and there is no reason for a game server process to reach the whole machine. Creating users and connecting with keys: connecting to a server over SSH

2. Installing with SteamCMD

Server files are downloaded with an anonymous Steam session; no account password is needed.

./steamcmd.sh +force_install_dir /home/cs2/server +login anonymous \
  +app_update APPID validate +quit

Replace APPID with the Steam application ID of the CS2 dedicated server; the correct value is in the game's official server documentation. A wrong ID does not throw an error, it silently downloads a different package — so do not guess it.

Use the validate parameter both on first install and after every update: it re-downloads missing or corrupted files and heads off most of the "server starts but the map will not load" class of problems.

Do not leave the server attached to your SSH session. Define it as a systemd service with Restart=always, otherwise it shuts down the moment the session closes.

3. GSLT and server configuration

A GSLT is tied to your Steam account and acts as your server's identity. Two practical consequences: you need a separate token for each instance, and if your server breaks the game's rules the token is suspended, which affects the other servers tied to your account too.

Your configuration file should at minimum set the server name, game mode, map cycle, admin password and RCON password. Do not leave the RCON password empty. On a server started with an empty password anyone can use RCON, and RCON is full control of the server.

In CS2 the tick rate cannot be changed: the server runs at a fixed 64 tick and Valve's sub-tick system timestamps player input between ticks. The -tickrate 128 parameter carried over from CS:GO has no effect in CS2. What matters is whether the server finishes every tick (about 15.6 ms) on time; when it cannot, movement and hit registration become irregular. Measure tick time under load and choose a processor with high per-core performance.

4. Ports

Increment the port number for each additional instance: 27016 for the second server, 27017 for the third. If the query port is closed the server runs but never appears in the list — the single most common cause of "my server is up and nobody can find it".

Do not expose the RCON port to everyone; where possible allow only your own IP address in the firewall.

Several instances on one machine

The common CS2 setup is not a single server but a network of them: competitive, retake, deathmatch. Because each instance runs in its own process, the calculation is simple — roughly 2 GB of RAM and one vCPU per instance. An 8 GB / 4 vCPU plan comfortably runs three to four instances; beyond that you need a processor family with more cores. At this scale staying on one machine is both cheaper and easier to manage than buying a separate virtual server per instance.

Run each instance from a separate install directory. Two processes sharing one directory overwrite each other's configuration and log files, and when something breaks you cannot tell which server did what. How to work out the cost per slot: game server slot planning

The most common first-boot mistakes

1. No GSLT, or a suspended one. The server starts cleanly, the console shows no error, and it is simply missing from the public list.
2. 27015 opened for TCP only. Game traffic travels over UDP, so players cannot connect.
3. A weak RCON password, or the port open to everyone. You have handed full control of the server outside.
4. Spending on RAM and ignoring clock speed. In CS2 the deciding factor is CPU work per tick; extra RAM does not show up in gameplay.
5. Running instances from one directory. Two processes write to the same files and diagnosis becomes impossible.
6. Not matching plugin versions to the game version. After a game update the server will not start until the plugin layer is updated; once you have applied it, join once yourself before opening to players.

On DDoS

CS2 servers are frequently hit with UDP floods on the game port. Because a UDP source address can be forged, this cannot be solved at the application layer; the traffic has to be filtered at the network layer. The full picture: what is DDoS protection?

On Datafex servers, layered Fexwall DDoS protection is included free on every plan.

Next step

We have put the recommended plans by player and instance count, the processor options and the CS2-specific questions on one page: CS2 server plans.