A VPS for a CS 1.6 server: ReHLDS, tickrate and a fast core
Counter-Strike 1.6 runs on the GoldSrc engine, and its dedicated server has modest requirements even by early-2000s standards. One 32-player server takes about 100–300 MB of memory, and several servers on different ports live comfortably on one VPS. But the lightness is deceptive: the server simulates the game in one thread, and how consistently hits register depends on how evenly the CPU delivers frames. Below is what to take into account so that your CS 1.6 VPS doesn't become the cause of complaints that hits "don't register".
HLDS or ReHLDS
The official HLDS server is installed through SteamCMD (app 90) and still works, but it has barely been updated for a long time. Most public servers today use ReHLDS, a compatible rework of the engine with bugs fixed, protection against some exploits and lower CPU load. It is usually paired with:
- ReGameDLL_CS: a reworked game library with additional game mode settings;
- Metamod-R and AMX Mod X: for plugins such as admin tools, statistics, map voting and VIP;
- ReAPI: an interface for plugins that need access to ReHLDS functions.
The server is 32-bit. On 64-bit Linux, which almost all hosts offer, you need to install 32-bit libraries (on Debian and Ubuntu, packages with the i386 suffix after dpkg --add-architecture i386). It's a standard operation, but without it the server won't start, and beginners often mistake this for the VPS being incompatible.
Tickrate, server FPS and the CPU
Two parameters determine how often the server updates the world. sys_ticrate sets the desired number of server frames per second, and sv_maxupdaterate sets how many times per second the server sends players the game state. The usual setting is a tickrate of 100 with the same updaterate; on ReHLDS many set sys_ticrate to 1000 so the server holds a high, steady FPS. What matters is not the number in the config but the actual FPS: the stats console command shows whether the server holds the configured value.
This is exactly where the weakness of cheap plans shows. If many neighbours share a physical core, the server's FPS jumps around, and players get delayed hit registration even with low ping. So for CS 1.6 look at single-core clock speed (3 GHz or more, higher is better) and fair resource allocation; KVM is preferable to container virtualisation. The VPS with high CPU clock speeds selection helps filter out slow plans. One core is enough for one server; if you plan a public server, a practice server and, say, servers for pick-up matches on one machine, take one core for each busy server.
Ping and location
CS 1.6 is played mainly in Russia and the CIS, and the game itself is very sensitive to latency. For players in Moscow and St Petersburg a ping of up to 20–30 ms is comfortable, so Russia is selected in the listing by default. A server in Moscow gives the lowest latency for the central part of the country; for an audience in the Urals or Siberia it's more sensible to choose a location closer to them. If your community plays elsewhere, pick a data centre close to it. If you also run servers for the newer game in the series, compare the requirements on the VPS for CS2 page: it needs a completely different amount of memory and CPU.
Attacks, ports and maintenance
Public CS 1.6 servers are attacked often, both with floods on the UDP port and with spoofed queries that make the server reply with large packets. ReHLDS partly addresses the second problem, but only filtering on the host's side protects against network floods. Plans with it are in the VPS with DDoS protection selection.
Practical tips:
- the main port is UDP 27015; put a second server on 27016 and up;
- run the server as a separate user, not as root, through systemd or screen with automatic restart;
- set a strong
rcon_passwordand don't publish it in the configs of server packs you share; - keep an eye on the size of AMX Mod X logs and demos: on a small disk they use up the space sooner than you'd think.
The most convenient systems are Debian or Ubuntu in their server editions: most guides for ReHLDS and server packs are written for them, and 32-bit libraries install from the standard repositories. Try engine and module updates on a test server on a neighbouring port first: a new version of ReGameDLL or AMX Mod X sometimes breaks old plugins, and players notice faster than the administrator.
The server needs only a small disk: the game with maps and sounds takes about 1–2 GB, so the smallest SSD will do. Fast downloads of maps and resources for players come not from the VPS disk but from file delivery set up through sv_downloadurl from a web server.