Space Station 14 Server Hosting

What does a Space Station 14 server actually run?

A Space Station 14 server runs one shift at a time: a round-based roleplay simulation where every player takes a job aboard a station, from engineer and chemist to security officer or captain, while hidden antagonists work against the crew. Rounds start in a lobby, pick a game preset and a map, and end with an evac shuttle or a smoking wreck.

Under the hood is Robust.Server, the open-source .NET engine the Space Wizards team built for SS14. The stock build is the upstream Wizard's Den codebase, but the same engine powers many community forks with their own content and rules. Whichever you choose, the server simulates atmospherics tile by tile, power grids, chemistry, physics and every item on the station, then streams the result to players.

Owning the server means you set the tone. A small group can run relaxed low-population shifts, a roleplay community can lock the doors with a whitelist, and a chaos-loving crew can leave the default secret preset on so nobody knows which antagonists are coming.

How much RAM and CPU does an SS14 station really use?

For most communities 4 GB is a real starting point: a small SS14 server runs comfortably in a few gigabytes, and memory climbs with player count, map size and the thousands of entities a busy station accumulates. Recording replays or running a content-heavy fork adds more on top.

CPU matters more than raw memory. The server advances the whole simulation every tick, and atmospherics, explosions and physics are the expensive parts; a hull breach during a fire is a far heavier tick than a quiet cargo shift. If your server_config.toml sets net.tickrate to 60, the SS14 docs note that dropping it to 30 is basically unnoticeable to players while cutting server, client and network load dramatically.

Every tier up to Diamond runs on 4 vCores; Emerald adds two more and Xtreme triples that to 12. Past a certain population, a smoother tick comes from lighter settings and a sensible soft player cap rather than more RAM, which is the honest reason the top tiers exceed what one SS14 station needs. The build itself is small; NVMe space mostly goes to logs, replays and the database.

Which server_config.toml settings should you change first?

Everything a stock SS14 server lets you change lives in server_config.toml next to the executable. Settings are CVars grouped under TOML headers, so game.hostname goes under [game] as hostname. A malformed line can keep your settings from loading, so edit with the server stopped.

Start with [game]: hostname is the name shown in the launcher, soft_max_players (30 by default) is the player cap, lobbyenabled keeps new arrivals in the lobby instead of dropping them into a round, and defaultpreset picks the mode, with secret as the default. map_pool and map_rotation decide which stations come up.

Under [auth], mode = 1 requires every player to have a proper SS14 account, the easiest way to stop guest-account griefing. Under [whitelist], enabled = true limits entry to players you have added to the database, which suits roleplay servers. Public listing is handled by advertise and tags under [hub], and replay.auto_record keeps footage of your most memorable disasters automatically. Many CVars can be tried live with the cvar command from an admin console before you commit them to the file.

Can you run a fork or add custom content?

Yes, but not by dropping files into the stock build. The SS14 docs state plainly that a pre-packaged server build can only be modified through server_config.toml; new content, rules or code need a build of their own.

There are two routes. To play an existing fork, download that fork's Linux server package from its builds page and upload it over SFTP in place of the stock files. If you maintain your own codebase, package it with the Content.Packaging tool using --hybrid-acz: the resulting server archive carries the client content, and the launcher downloads it from your server when players connect, so nobody installs anything by hand.

Custom server rules follow the same logic. The stock build ships with no rules; the documented method is a guidebook entry in your fork, pointed to by the server.rules_file CVar. Whatever build you run, keep the data folder and server_config.toml when you swap versions, because that is where characters, playtime, bans and admin ranks survive the update.

How do you get admin rights and let players connect?

A fresh SS14 server has no admins at all, and the docs list three ways to get the first +HOST rights. Connecting from localhost grants them automatically, which does not help on a hosted server. The practical options are setting console.login_host_user to your SS14 username in server_config.toml, or typing promotehost followed by your name in the panel console while you are connected. After that, the permissions command hands out admin ranks in game. Treat +HOST like a root password; the docs warn it is enough to take over the entire server.

Players connect through the Space Station 14 launcher. For a private server, share your IP and port; players choose Direct Connect To Server and can press Add Favorite so the station stays in their list. SS14 uses the same port number over UDP for gameplay and over TCP for the status API the launcher reads, so if direct connect works but the launcher shows the server offline, the TCP side is the first thing to check. Turn on hub.advertise and, having accepted the hub rules, your station appears in the public list.