To make an Insurgency: Sandstorm server, install the dedicated-server package with SteamCMD (App ID 581330), launch the correct platform executable with a valid map and scenario, authenticate it when browser discovery requires it, and expose separate UDP game and query ports. You can run those steps on your own Windows or Linux host, or use a managed provider that supplies a control panel and assigned ports. The reliable way to troubleshoot is to validate one scenario first, test a direct connection through the game port, and only then diagnose browser listing through the query port.
This guide reflects the setup boundary around Update 1.21, with scenario and package details checked through July 2026. Map names, scenario identifiers, provider fields and token workflows can change after an update, so treat those items as version-sensitive.
Should you self-host or use a managed provider?
Choose the operating model before copying any commands. A self-hosted SteamCMD installation gives you access to the executable, configuration directories, firewall, update schedule and service manager. A managed provider deploys the package and usually gives you restart controls, backups and token fields, but may hide files or rename settings.
| Area | Self-hosted SteamCMD | Managed provider |
|---|---|---|
| Installation | You install and validate App ID 581330. |
The provider deploys the dedicated package. |
| Files | You can edit the executable, Saved/Config and Config/Server. |
The panel may expose only selected files or variables. |
| Networking | You select and forward available UDP ports. | The provider may assign game and query ports. |
| Operations | You maintain updates, firewall rules and restarts. | The panel commonly supplies restart controls and provider-side networking. |
| Troubleshooting | You inspect the host, firewall and service logs. | You must also check provider networking and how panel fields map to switches. |
Do not mix the two workflows. A provider’s startup field might generate an ADDSWITCHES argument, while a self-hosted installation expects a file under Insurgency/Saved/Config. If you use a panel, follow its assigned ports and documented variable names instead of forcing self-hosted defaults.
What do you need before installing the server?
- A Windows or Linux machine that can remain online while players connect.
- SteamCMD and permission to create the server directory.
- Two reachable UDP paths: one for game traffic and one for browser queries.
- Access to your firewall and router, unless the provider manages them.
- A valid map/scenario pair from the build you installed.
- A Steam Game Server Login Token (GSLT) if you want normal Steam authentication and discovery, plus a separate stats token only if you use game statistics.
The files are digital. You do not need a physical game disc or a particular Amazon hardware item to install the dedicated package. Hardware, electricity and hosting charges still depend on whether you run the machine yourself or rent a service.
How do you install the Insurgency: Sandstorm dedicated server with SteamCMD?
Valve’s Steam Support guidance says SteamCMD is the distribution method for standalone Steam game servers. Use the dedicated-server App ID, not the retail game’s App ID.
- Install SteamCMD for your operating system and open a terminal or command prompt.
- Choose a server root with enough free disk space and write permission.
- Run the installation and validation command:
steamcmd +login anonymous +force_install_dir "/path/to/sandstorm-server" +app_update 581330 validate +quit
+force_install_dir sets the destination, +app_update 581330 validate downloads or repairs the dedicated package, and +quit closes SteamCMD. On Windows, replace the path with a valid directory such as C:SandstormServer; on Linux, use an absolute path such as /srv/sandstorm-server.
If anonymous login is rejected by your local SteamCMD workflow, follow Valve’s current account requirements rather than switching to the retail game executable. Updating App ID 581320 installs the retail game, not the dedicated server.
Where are the executable and configuration files?
The executable and configuration tree differ by platform. A new installation may not create the platform-specific configuration directory, so create it before adding files.
| Platform | Executable | Platform configuration directory |
|---|---|---|
| Windows | InsurgencyServer.exe |
Insurgency/Saved/Config/WindowsServer |
| Linux | Insurgency/Binaries/Linux/InsurgencyServer-Linux-Shipping |
Insurgency/Saved/Config/LinuxServer |
Keep shared text lists in Insurgency/Config/Server. That location is appropriate for list-style files such as admin IDs and map-cycle data. Put platform-specific .ini settings under the matching WindowsServer or LinuxServer directory.
Do not put Game.ini in the server root, place Windows settings under LinuxServer, or assume a hosted panel exposes these paths. In a managed installation, the provider may write files for you or translate a panel field into a command-line switch.
How do you choose a valid map and scenario?
Start with one explicit map/scenario pair. Display names and internal scenario identifiers are not interchangeable, and older examples can refer to scenario families that no longer match the installed build.
- Install or update the server package.
- Start the executable in a controlled console session.
- Use the build’s
mapsandscenarioscommands, or consult the provider’s current scenario list. - Copy the exact internal identifiers into your launch line.
- Only add a rotation after the first map boots successfully.
The setup information covered Update 1.21, with a July 15, 2026 minor-patch boundary and dedicated-server package metadata checked through July 23, 2026. A later patch can add, rename or retire identifiers, so a command copied from an older post may fail even when the executable itself is healthy.
What should the first launch command look like?
The launch line has two syntactic zones. The travel string contains the map and question-mark parameters. Dash-prefixed command-line switches such as -Port and -QueryPort come after that travel string.
Windows example
InsurgencyServer.exe MAP_NAME?Scenario=SCENARIO_ID?MaxPlayers=28 -Port=27102 -QueryPort=27131 -hostname="My Server" -log
Linux example
Insurgency/Binaries/Linux/InsurgencyServer-Linux-Shipping MAP_NAME?Scenario=SCENARIO_ID?MaxPlayers=28 -Port=27102 -QueryPort=27131 -hostname="My Server" -log
Replace MAP_NAME and SCENARIO_ID with values confirmed on your build. MaxPlayers=28 is an example, not a universal limit; the mode and current build determine the practical capacity. Common travel parameters include lighting, a password and mutators. Keep those parameters in the travel/configuration portion rather than moving them after the dash-prefixed switches.
Run this first with one map, one scenario and no optional mutators. A minimal launch makes it easier to tell whether a failure comes from the executable, the scenario, authentication or networking.
Which tokens does the server use?
Three identifiers are often confused:
- Dedicated package App ID:
581330, used by SteamCMD to install and update the server. - Steam Game Server Login Token (GSLT): authenticates the server for Steam behavior and discovery. The Gamers.Wiki workflow for creating one references the retail game App ID
581320. - GameStatsToken: a separate optional credential used with
-GameStatsfor stats or XP services.
A self-hosted launch can include the following when you have both credentials:
-GSLTToken=<steam_gslt> -GameStatsToken=<gamestats_token> -GameStats
Do not substitute a stats token for a GSLT. A process can start and accept a direct connection while still failing to appear in the expected browser because discovery or authentication is incomplete.
Provider panels may create a confusing exception. One managed setup labels fields GST and GSLTT and instructs its users to create tokens with App ID 581330, while the separate token-creation workflow cited above references 581320. Treat those as provider-specific instructions: ask which command-line switch each field generates, then verify the resulting startup line rather than guessing from the label.
Which ports must you open?
Use two separate UDP rules. The conventional self-hosted values are UDP 27102 for game traffic and UDP 27131 for query or browser traffic. They are conventions, not immutable numbers.
| Purpose | Typical self-hosted value | What it tests |
|---|---|---|
| Game endpoint | UDP 27102 |
Player connections and direct joins |
| Query endpoint | UDP 27131 |
Server-browser queries and listing data |
If your provider assigns different values, use the Network tab’s game and query ports in both the panel and firewall. Do not force 27102 and 27131 onto a managed instance unless the provider explicitly says those ports are available.
Self-hosted firewall and router checklist
- Allow the server executable through the host firewall.
- Create inbound UDP rules for the active game and query ports.
- Forward those same UDP ports from the public router address to the server’s private address.
- Reserve the server’s local IP so a DHCP change does not break forwarding.
- Check whether your ISP uses carrier-grade NAT (CGNAT); inbound forwarding cannot work normally when you do not receive a reachable public address.
Keep the game and query values consistent across the launch line, firewall, router and provider panel. A mismatch can look like a game bug even when the process is running correctly.
What is the correct order for testing?
Test in a controlled sequence so each result identifies a different failure domain.
- Confirm the process stays running. Watch the console or service log for an exit, crash or repeated restart.
- Confirm the scenario. Verify that the map and scenario identifiers appear in the installed build’s command output and that the server finishes loading.
- Compare endpoints. Match the active game and query ports to the launch line or the provider’s assigned values.
- Try a direct join. From the game console, use
open YOUR.SERVER.IP:PORT, replacingPORTwith the game endpoint. - Search the browser. Look up the hostname, map or mode after the direct game-port test succeeds.
A direct join tests the game endpoint only. If it works but the browser cannot find the server, investigate the query UDP rule, token mapping, provider filtering and assigned-port handling instead of replacing a valid scenario command.
How do you configure passwords, administrators, rotations and RCON?
For self-hosting, place platform-specific settings in Saved/Config/<platform>Server and list files in Insurgency/Config/Server. Typical list files hold administrator IDs and map-cycle data. Restart the server after changing files so you know the new configuration was loaded.
Managed panels may expose the same features as startup variables or an ADDSWITCHES field. Examples documented for hosted setups include:
-Password=YOUR_PASSWORD -MapCycle=YOUR_CYCLE -mutators=YOUR_MUTATORS -GameStats -Rcon -RconPassword=UNIQUE_SECRET -RconListenPort=YOUR_RCON_PORT
- Use a long, unique RCON password and restrict the RCON port to trusted addresses whenever possible.
- Do not enable cheats on a public server.
- Mutators can affect browser filtering; disclose them in the server name or description when players need to know.
- Confirm whether a panel field writes
Game.ini, a server text file or anADDSWITCHESargument. A setting that is stored in the wrong place will appear to have no effect.
How many players can the server support?
Capacity depends on mode and build. A 2026 hosted-capacity table gives these examples for the researched build:
| Mode example | Advertised upper limit |
|---|---|
| Checkpoint co-op | Up to 8 players |
| Hardcore Checkpoint co-op | Up to 8 players |
| Survival co-op | Up to 8 players |
| Several versus modes | Up to 28 players |
These are mode examples tied to that researched build, not a promise for every future update. Set MaxPlayers to a value supported by your selected scenario and test a full rotation before advertising the number.
How do you keep the server running after updates and reboots?
Save both a start script and an update script. The update script should stop the service cleanly, run SteamCMD validation against App ID 581330, and then start the service again. Re-check map names, scenario identifiers, token behavior and provider fields after each game release.
Windows
Use Task Scheduler to launch the start script at boot and to restart it after an unexpected exit. Run the task under an account with access to the server directory and network ports, and write console output to a log file for later diagnosis.
Linux
Use a systemd service with a restart policy, a working directory set to the server root and a dedicated service account. Keep SteamCMD updates separate from the running process so an executable is not replaced while it is serving players.
A provider estimate of roughly 2–3 GB of memory and one fast CPU core is a sizing signal, not an official minimum. Actual requirements vary with mode, player count, operating system, logging and other workloads.
Why does SteamCMD fail to finish?
- Verify that the destination path exists and that the account running SteamCMD can write to it.
- Confirm that you are updating App ID
581330, not retail App ID581320. - Check the login mode and follow any current Valve account requirement if anonymous login is refused.
- Run the command again with
validateafter correcting the path or authentication issue.
Why does the process start but the scenario fail?
Re-check the exact map and scenario output from the installed build. Display names copied from a web guide may differ from internal identifiers, especially after Update 1.21 or a later minor patch. Remove optional mutators and rotation entries, boot one known pair, and add complexity only after that map loads.
Why does a direct join fail?
- Confirm that you are using the game port, not the query port.
- Compare the launch line with the host firewall and router’s inbound UDP rules.
- Check NAT and CGNAT conditions; a private or carrier-grade address can prevent unsolicited inbound traffic.
- If the server is managed, use the provider’s assigned game endpoint rather than the conventional
27102. - Confirm that the process is still running and listening after the map loads.
Why does direct join work but the browser listing fail?
This result isolates the problem to discovery rather than the game endpoint. Check the query UDP port, GSLT mapping, provider authentication, browser filters and whether the provider assigned a different query port. A missing or mis-mapped token can allow direct connections while preventing the expected Steam listing.
Why does a panel setting have no effect?
Find out what the field actually writes. Some panels edit Game.ini, some generate a server text file, and others append an ADDSWITCHES command-line argument. Save the setting, restart according to the provider’s procedure, and inspect the resulting startup line or log before changing unrelated options.
Frequently Asked Questions
Can I run an Insurgency: Sandstorm server without owning the game?
The dedicated files are distributed separately through SteamCMD, so a physical disc is not required. You still need a host with reachable networking and, for normal Steam discovery, the appropriate server authentication credentials; hosting and bandwidth costs depend on your setup.
Can I host the server behind CGNAT?
Usually not for ordinary public inbound connections, because CGNAT prevents you from forwarding a public address to your machine. Use a host with a real public IPv4 address, a provider that handles the networking, or a supported tunnel solution rather than repeatedly changing the scenario command.
How do I change the server name without changing the map?
Edit the -hostname value in the startup command or the provider field that generates it, then restart the server. The hostname is independent of the map/scenario travel string, so changing it does not require a new scenario identifier.
What should I back up before updating the server?
Back up your platform-specific Saved/Config directory, shared files in Insurgency/Config/Server, start and update scripts, and token or port documentation. Keep the backup outside the live server root so SteamCMD validation cannot overwrite it.