SRCDS basics: launch options and cfg

SRCDS - the Source Dedicated Server - is one program that runs every Source 1 game: Team Fortress 2, Garry's Mod, Counter-Strike: Source, Left 4 Dead 2, Half-Life 2: Deathmatch, Day of Defeat: Source and a long tail of mods. You install the game's server files with SteamCMD, start srcds_run (Linux) or srcds.exe (Windows) with -game <folder>, a starting map and a player count, and the rest of the behaviour comes from server.cfg in the game's cfg folder. The launch line decides what the server is; the cfg files decide how it behaves. Once you know which settings belong where, every Source game is the same server with different content.

One engine, many games#

Every Source 1 server shares a binary and a layout. The -game argument picks the content folder, and that folder holds everything game-specific:

Counter-Strike 2 is not on this list. It runs on Source 2, uses a different binary (cs2 with -dedicated), a different folder layout (game/csgo/), a different plugin stack and a different map system. Many cvars carried over, which makes old guides misleadingly half-right; Counter-Strike 2 server setup covers it properly. Counter-Strike 1.6 is older still - GoldSrc, run by hlds - and is in the Counter-Strike 1.6 server guide.

Installing any of them is the same SteamCMD line with a different id. All of these allow anonymous login:

$ steamcmd +force_install_dir /home/srcds/tf2 +login anonymous \    +app_update 232250 validate +quit

SteamCMD explained covers what each part of that line does and why validate will overwrite files you edited inside the game's own folders.

The launch line, option by option#

On Linux you start the server through srcds_run, a shell wrapper around the real binary (srcds_linux). The wrapper handles restarting on crash and optional auto-updates. On Windows, srcds.exe is started directly. A typical line:

$ ./srcds_run -game tf -console -port 27015 +maxplayers 24 \    +map ctf_2fort +sv_setsteamaccount YOURTOKEN -strictportbind

Two kinds of argument appear on it, and the difference matters:

• Dash options (-game, -port, -console) are read by the engine or the wrapper at process start. They configure the process itself.
• Plus commands (+map, +maxplayers, +exec) are console commands queued to run once the engine is up, exactly as if typed into the console. Any cvar can be set this way.

The options worth knowing:

Three of these cause most of the trouble.

`+map` is not optional. A Source server with no map loaded does not appear in the browser and accepts no connections. It is not crashed; it is waiting.

`+maxplayers` is fixed at start. Changing it in server.cfg does nothing, because server.cfg runs after the slot count is decided. Every game also has a ceiling: TF2 allows up to 100, L4D2 is built around 4 survivors (8 in versus) and needs plugins for more, and Garry's Mod goes up to 128.

`-tickrate` is game-dependent. CS:S respects it, which is why "66-tick" and "100-tick" CS:S servers exist. TF2 is fixed at 66 and ignores it. Garry's Mod accepts -tickrate and many roleplay servers lower it to save CPU. What tick rate actually means covers the trade.

Game server login tokens

+sv_setsteamaccount takes a token generated on Steam's game server account management page, tied to the game's client app id (440 for TF2, 4000 for Garry's Mod). Whether you need one depends on the game: without one, most Source 1 servers log in anonymously and work, though some list poorly or restrict features. CS2 requires one to be listed at all. Steam game server tokens has the details, including the "token in use" error when two servers share one.

The cfg folder and the order things run#

Everything after the launch line lives in <game>/cfg/ - tf/cfg/, garrysmod/cfg/ and so on. These are plain text files of console commands, one per line, with // comments. The engine runs some automatically:

1. valve.rc at start, which by default calls autoexec.cfg. Use autoexec.cfg for things that should happen once per process start.
2. server.cfg after every map load. This is where nearly everything goes, and it runs again on every map change, so changes to it take effect on the next map without a restart.
3. Anything a plugin runs. Map-config plugins for SourceMod, for example, execute a file per map or per map prefix after server.cfg, which is how one server runs different settings on ctf_ and pl_ maps.

Anything else runs only when something calls it: exec mysettings from the console, +exec on the launch line, or an exec line inside server.cfg. Splitting a long config into exec-ed pieces (exec banned_user.cfg, exec competitive.cfg) is normal and keeps it readable.

A reasonable starting server.cfg for a public TF2 server:

hostname "Ten-Second Respawns | 2Fort and friends"sv_password ""rcon_password ""sv_contact "admin@example.org"sv_region 3sv_lan 0mp_timelimit 30mp_winlimit 0mp_maxrounds 0sv_allowupload 0sv_allowdownload 1sv_downloadurl ""log onsv_logbans 1sv_logecho 1sv_logfile 1exec banned_user.cfgexec banned_ip.cfg

Notes on the ones people get wrong:

• rcon_password "" disables remote console. That is the right default; set one only if a tool needs it, and read RCON safely first.
• sv_region is a number used for browser filtering. 255 is "world"; the others are regional codes, and 3 is Europe.
• sv_lan 1 hides the server from the internet and drops non-LAN clients. It is for LAN events, and setting it by mistake is a classic "server works locally, nobody can join".
• sv_downloadurl points at a web server holding compressed custom content (FastDL). Without it, clients download maps slowly from the game server itself, if sv_allowdownload is on at all.
• banned_user.cfg and banned_ip.cfg are written by writeid and writeip. Bans made with banid and addip live in memory until written, and a restart forgets them if nobody did.

Other files in the game folder

Around cfg sit a few more files the server reads:

• cfg/mapcycle.txt in TF2 (it lives in the game root in some older games): the maps the server rotates through, one per line. The cvar mapcyclefile can point elsewhere. Rotation in depth is in game server maps and map rotation.
• motd.txt and motd_text.txt: the message of the day shown on join, as HTML or a URL, with the text version for clients that turn HTML off.
• addons/: where Metamod:Source and SourceMod live, if installed.
• maps/, materials/, models/, sound/: custom content, which clients must download too.

Ports and connecting#

Source 1 answers browser queries on the game port itself, so there is no separate query port to forward. If you change -port, RCON moves with it. SourceTV runs as an extra client on its own port and occupies a slot; -nohltv removes it when you do not want spectators or demos.

Players connect with connect 203.0.113.10:27015 in the game console, through the server browser's Favourites tab, or with a steam://connect/203.0.113.10:27015 link. Steam connect links and direct connect covers the variants, including passwords on the link. If the server answers by IP but never shows in the browser, check sv_lan, then the Steam login, then give the master server a few minutes - game server ports explained goes further.

Resources: what a Source server actually uses#

Source 1 servers are light by modern standards, and that is the reason they are still cheap to run twenty years on. The engine simulates the game on a single main thread, so what decides whether a server keeps its tick is one core's speed, not the number of cores. A second core helps only with the work around the edges: SourceTV, logging, plugin threads.

Memory grows with custom content and plugins rather than with players. A TF2 server with a few hundred custom maps in rotation holds more than one running the stock list, and a Garry's Mod server with a large Workshop collection can use several gigabytes before anyone joins. CPU grows with players, tick rate and plugins that run every frame - which is why one badly written plugin can do more damage than ten extra players.

The number that tells you whether a server is healthy is not CPU percentage but whether it holds its tick. The stats console command prints frame rate and CPU; net_graph on a client shows the server's sv frame rate and its variance. A server whose frame time spikes past the tick interval drops simulation steps, and players feel that as hit registration they do not trust. Why TPS drops and what to do uses Minecraft as its example, but the method - measure first, then find what costs time per tick - is the same. If the panel graph shows one core flat at its ceiling, a faster core helps; more memory does not.

Logs and the console#

Source has three separate kinds of logging, and confusing them is why people "cannot find the logs":

• Console output: what you see in the panel. Gone when the process exits unless captured. -condebug on the launch line writes it to console.log in the game folder.
• Server logs: switched on with log on, written to <game>/logs/ as L followed by a date and sequence number (L0712001.log). They record connections with SteamIDs and IPs, chat, kills, kicks and bans, and are what any moderation dispute comes down to. sv_logecho 1 mirrors them to the console.
• Plugin logs: SourceMod writes its own under addons/sourcemod/logs/, with errors in errors_<date>.log. A broken plugin rarely crashes the server; it just fills that file.

Old L*.log files are never deleted by the server. On a busy server they quietly fill disk over months, so trim them on a schedule. Logs worth keeping suggests what to keep and for how long.

Admins, plugins and what vanilla lacks#

Vanilla SRCDS has no admin system beyond RCON. Anyone with the RCON password can run any command; nobody else can do anything. That is why almost every Source server installs Metamod:Source and SourceMod, which add admins with flags, immunity, voting, map management and thousands of plugins. Garry's Mod is the exception: it ships with Lua scripting and uses its own admin addons, typically ULX or SAM.

Installing SourceMod is unpacking two archives into the game folder and restarting. Admins then go in addons/sourcemod/configs/admins_simple.ini:

"STEAM_0:1:12345678"   "99:z"    // full admin, top immunity"[U:1:24691357]"       "bcdfg"   // kick, ban, slay, map, cvars

The flags and immunity levels are covered in SourceMod admin flags and immunity, and a broader comparison across games is in game server admin plugins compared. For TF2 specifically, Team Fortress 2 SourceMod plugins walks the install.

Updates, 64-bit and crashes#

Valve pushes Source updates without notice, and an outdated server is refused by updated clients. srcds_run can handle it: with -autoupdate, -steam_dir and -steamcmd_script it runs SteamCMD before each restart. Panels do the equivalent by updating on start. Either way the procedure is the same - stop, update, start - and a server with plugins should be updated only after you know the plugins survived the patch. The update day checklist covers the order.

In 2024 Valve released 64-bit Linux server binaries for TF2 and several other Source games, with a srcds_run_64 wrapper beside the old one. The 64-bit build fixes memory ceilings that plagued large servers, but Metamod and SourceMod needed matching 64-bit releases and older plugins compiled for 32-bit stopped working. If a plugin loads on one binary and not the other, that is the reason.

srcds_run restarts the server after a crash unless -norestart is set, and writes core dumps if the system allows. Crashes that recur on the same map usually mean a broken custom map or a plugin hooking map entities; crashes on player join usually mean a plugin; crashes after an update usually mean Metamod or SourceMod gamedata out of date. The reliable test is to start the server with Metamod's loader file (addons/metamod.vdf, or its 64-bit counterpart) moved aside, which disables the whole plugin stack in one step.

FAQ#

What is the difference between srcds_run and srcds_linux?

srcds_linux is the real server binary. srcds_run is a shell script that sets up library paths, runs it, restarts it after a crash and optionally updates it first. Start through the script unless you have a reason not to.

Why does my maxplayers setting in server.cfg not work?

Because maxplayers is fixed when the process starts and server.cfg runs later, at map load. Put +maxplayers 24 on the launch line instead - on a panel, it is usually a field on the Startup tab.

Do I need a Steam token for a TF2 or Garry's Mod server?

It is not required in the way it is for CS2. Without one the server logs in anonymously and generally works. A token gives the server a persistent identity, which some listing sites and favourites rely on, so it is worth having for a public server.

Can one srcds install run several games?

No. Each game is its own SteamCMD app with its own files, even though the binary looks the same. Install each game separately and run each as its own server.

Is SRCDS the same thing as the CS2 server?

No. CS2 runs on Source 2 with a different binary, layout and plugin system. Cvars like sv_password and hostname look familiar, but launch options, map groups and plugins are different.