Stationeers dedicated server setup

A Stationeers dedicated server is a free download (Steam app 600760, anonymous login) that runs on both Linux (rocketstation_DedicatedServer.x86_64) and Windows (rocketstation_DedicatedServer.exe). In current versions it is configured almost entirely on the command line: -file start <name> <world> loads or creates a station, and -settings followed by key-value pairs sets the name, password, ports and save interval. It uses UDP 27016 for the game and UDP 27015 for Steam, saves into a saves folder beside the executable, and spends its CPU on the atmosphere and pipe simulation rather than on players. The launch syntax changed when the server was reworked, so if a guide tells you to use -load with a long list of flags, it predates the current server.

How Stationeers multiplayer works#

Stationeers is a simulation game first: every room has an atmosphere with pressure, temperature and gas mixture, every pipe network has the same, and power, logic chips and devices all tick on the server. In multiplayer the server owns that simulation, and clients see the results. Three consequences:

• The server's CPU decides how big a base can get before the simulation slows down. Player count matters far less than the number of atmospheres, pipe networks and devices.
• The world keeps running when nobody is on, unless you tell it to pause. Plants grow, batteries drain, a leaking pipe keeps leaking. AutoPauseServer exists for that reason.
• Everyone must run the same version. Stationeers updates often, and clients on a newer build cannot join an older server.

A hosted game from the main menu works for a quick session, but the station exists only while the host plays. A dedicated server is the right tool for a group that plays at different times or runs long projects. What a dedicated game server is goes through the difference in general.

Planning a station that the server can carry

Because the simulation is the cost, how a group builds decides how long the server stays smooth. A few habits make a large difference, and they are easier to agree on before the first wall goes up than after the base sprawls.

Build compact. Every sealed room is an atmosphere the server has to calculate, and every exposed surface exchanges heat with the outside. A tight base with a few larger rooms is cheaper than a village of small huts connected by airlocks, and it is easier to keep pressurised anyway.

Keep pipe networks separate. Splitting a long network with valves, regulators or pumps turns one large calculation into several small ones and makes leaks easier to find. It also stops one mistake - a burst pipe in the greenhouse - venting the whole base.

Give people roles. Multiplayer Stationeers works best when one person owns atmospherics, one owns power, and one owns food or mining. Two people rebuilding the same gas network at once is how bases get vented, and it is hard to undo once the server has saved.

Clean up as you go. Ore piles, spent canisters and abandoned kits are all objects that the server tracks. Put them in storage or recycle them. A tidy base is a faster base.

Write logic sparingly. IC chips are one of the best parts of the game, but a chip that rewrites dozens of devices every tick costs CPU. Scripts that only act when something changes are cheaper.

None of this is enforced by settings. It is the equivalent of building rules on other games, and on a shared server it is what decides whether the station still runs at full speed after a month of play.

Requirements and resource usage#

Stationeers' server is not light, and it gets heavier as the station grows. The numbers below are typical starting points for the server process; a big late-game base on a harsh world can need more.

• CPU is the real limit. The atmosphere simulation is heavy and parts of it are bound to one thread, so clock speed matters. CPU vs RAM for game servers explains why adding memory will not help a simulation-bound server.
• Memory grows with the size of the explored and built-up area and with the number of things in the world - every dropped ore and every placed device is an object.
• Disk: the server installs to a few gigabytes. Saves grow from a few megabytes to tens or hundreds of megabytes for a large base; keep space for several.

The official wiki's recommendations for the machine running a server are generous, and they are right to be: a Stationeers server that runs out of CPU does not crash, it simply runs the simulation slower than real time, which feels like lag to everyone.

Installing and first start#

On Linux:

$ steamcmd +force_install_dir /home/stationeers/server +login anonymous +app_update 600760 validate +quit$ cd /home/stationeers/server$ ./rocketstation_DedicatedServer.x86_64 -file start MyStation Lunar \    -logFile ./server.log \    -settings StartLocalHost true ServerVisible true GamePort 27016 UpdatePort 27015 \    ServerName "Outpost Kepler" ServerPassword "long-join-password" ServerMaxPlayers 6 \    LocalIpAddress 0.0.0.0 AutoSave true SaveInterval 300

On Windows the executable is rocketstation_DedicatedServer.exe with the same arguments. SteamCMD explained covers keeping the install updated.

The -file start syntax

-file start loads the most recent save for the named station. If there is none, it creates a new world with the parameters given and saves it:

-file start <stationname> [worldid] [difficulty] [startcondition] [startlocation]

The world IDs carry version numbers because worlds have been rebuilt over time. The list above is current at the time of writing; new or renamed worlds appear with updates, and the dedicated server guide on the official Stationeers wiki is the place to check.

Once the station exists, the same command line keeps loading it. You only need the world and difficulty the first time, but leaving them in is harmless.

First start checklist

1. Start with -file start and a new station name.
2. Watch the log until the world is generated and the server reports it is listening.
3. Join from the game and check you land where you expect.
4. Stop the server cleanly, so the first save is written.

Settings: the -settings flag and setting.xml#

Everything after -settings is a series of key-value pairs. The ones that matter:

The server also writes a setting.xml after its first start. You can edit it, but the official guide warns that this has been unreliable - values have been ignored or overwritten - and recommends putting everything on the -settings line instead. On a panel, that means the startup command or startup variables, which is where the values belong anyway.

Ports and connecting#

Both must be open and both are UDP. If your host gives you different numbers, set GamePort and UpdatePort to match. On Linux, LocalIpAddress 0.0.0.0 matters: without it the server can bind to the wrong interface and be unreachable from outside, even with the ports open. Game server ports explained covers why games split traffic across two ports.

Players join through the in-game server list (with ServerVisible true) or by entering the address and game port directly. Direct join is more reliable while a new server is still propagating to the list.

Admin access and console commands#

The server console accepts commands. help lists them, with their arguments; the ones you will use most are save (force a save), quit (save and stop cleanly) and ban. The exact set has changed with the server rewrites, so treat help on your version as the reference rather than any older list.

Admins can also run server commands from inside the game. The same ServerAuthSecret value has to be set in the server's -settings line and in the admin's own client setting.xml. With that in place, the admin opens the in-game console (F3) and prefixes server commands with serverrun, for example serverrun save. Anyone who has the secret can do anything the console can, so treat it like a password and change it when an admin leaves.

Stationeers has no fine-grained permission system in vanilla. For a private group the password is the main control; for a public server, expect to rely on bans and a written set of rules - server rules, moderation and staff covers the basics.

Mods#

Stationeers mods come in two kinds:

• Content mods from the Steam Workshop - new items, recipes, tweaks to data files.
• Code mods that change game logic. These usually rely on a community mod loader on both the server and the clients.

The rules that apply to any modded multiplayer game apply here with extra force, because Stationeers updates often and changes its internals between updates:

1. Every player needs the same mods at the same version.
2. A game update can break code mods until their authors catch up. Do not update a modded server the day a patch lands.
3. Back up the save before adding or removing a mod. Removing a mod that added items or structures can leave the save unloadable.

How mods are loaded on a dedicated server has changed alongside the launch syntax, so follow the instructions for the mod loader and version you use rather than a generic recipe. What to do when a mod update breaks has the general recovery routine.

Saves, backups and performance#

Saves live in the saves folder beside the executable, one per station name, with the server keeping recent autosaves. A clean quit saves first; a killed process loses everything since the last autosave. With SaveInterval 300, that is at most five minutes - keep it there or lower on a busy station.

Back up the saves folder off the machine on a schedule, before every update and before every mod change. Stationeers has changed its save format in major updates; a backup from before the update is your way back if the new version will not load your station. Backups that actually restore covers the habit of testing a restore.

To move a local game onto the server, copy the station's save from your game's save folder into the server's saves folder with the server stopped, then start with -file start and that station name. Check the log to confirm it loaded rather than generating a fresh world with the same name.

When the simulation slows down, the usual causes are:

• Huge pipe networks. One network spanning the whole base is simulated as one big atmosphere. Splitting networks with valves and regulators helps.
• Many small sealed rooms each needing their own atmosphere calculation.
• Logic chips running heavy scripts on every tick.
• Thousands of loose items - ore piles, dropped ice, abandoned kits. Tidy them into storage.

A scheduled restart once a day, with a warning, also helps a long-running server - see restart schedules that help.

On RE:NODE the Startup tab is where a server's launch variables live, the Schedules tab can chain a backup and a restart, and backup slots on every plan are stored off the machine and restored with a button. Stationeers is not in the catalogue, so this is a description of the panel, not a Stationeers plan.

Troubleshooting#

The server starts but nobody can connect. Ports, then binding. Check both UDP ports are open, and on Linux set LocalIpAddress 0.0.0.0.

Settings in setting.xml are ignored. Known behaviour. Put them on the -settings line.

A new world appeared instead of my station. The station name on -file start does not match the save name exactly.

Players get a version mismatch. The game updated. Update the server with SteamCMD and restart.

Everything feels slow, but CPU is not at 100%. Check whether one core is at its limit; the simulation is bound to it. See why your game server keeps restarting if slowness ends in crashes.

FAQ#

Is the Stationeers dedicated server free?

Yes. It downloads anonymously through SteamCMD. Players need the game; the server does not.

Which world should a group start on?

The Moon (Lunar) is the usual first world: survivable, with a simple atmosphere problem. Mars and Europa add harder challenges; Vulcan and Venus are for groups who know the game well.

Why do old guides use -load and lots of flags?

Because the launch syntax changed when the dedicated server was reworked. Current builds use -file start and -settings; old commands may fail or behave differently.

Should AutoPauseServer be on?

For most groups, yes. It stops the station degrading while nobody can react. Turn it off only if you want long production chains to run overnight and trust your base to survive unattended.

How often should the server save?

Every five minutes is a good default. A save is quick on small stations, and losing more than five minutes of complex building to a crash is painful.