How to Build a Space Station 14 Server From Source (Forks Included)

The official Space Station 14 downloads cover upstream vanilla only — a stable build updated monthly, plus a "Vulture" testing build that tracks master. But SS14's communities largely live on forks: Goob Station, Delta-V, Frontier, Einstein Engines and dozens more, each with its own rules, content and codebase. Forks ship as source code; some publish prebuilt server artifacts, many don't. So check your fork's releases or builds page first — and when there's no build for your fork, or you're carrying your own changes on top of one, you compile it yourself.

This guide covers the whole path: tools, cloning a fork, building, packaging a production server that delivers your custom client to players automatically, and keeping the thing updated without breaking it. For running a standard server without compiling anything, start with our SS14 server hosting guide instead.

One rule above all of this: the commands below are the upstream process. Most forks follow it, some don't — a fork's README and its global.json always win over this guide.

TL;DR — the whole process (upstream)

# 1. Install Git, Python 3.7+ and the .NET SDK your codebase pins
#    (check global.json in the repo root — 10.x for upstream)
# 2. Clone the hosting branch (never "Download ZIP" — it misses the submodules)
git clone --branch stable https://github.com/space-wizards/space-station-14.git
cd space-station-14
# 3. Initialise submodules
python RUN_THIS.py
# 4. Build, then test-run locally
dotnet build --configuration Release
dotnet run --project Content.Server --configuration Release
# 5. Package a production server (bundles your client in too)
dotnet run --project Content.Packaging server --hybrid-acz --platform linux-x64
# 6. On the host: extract release/SS14.Server_linux-x64.zip,
#    chmod +x Robust.Server, then ./Robust.Server

The game host also needs the matching .NET runtime (not the ASP.NET Core one) — the SDK on your build machine doesn't travel with the package.

When compiling is actually worth it

• You're running a fork with no server build. Many forks ship source only. Check the fork's releases or builds page before doing it the hard way — if they publish server artifacts, you may not need any of this.
• You're building your own content. Custom ruleset, sprites, maps, game modes — anything beyond config-file tweaks means a custom build.
• You need a fix from master now. Upstream deploys to stable monthly (urgent fixes faster), so a non-urgent fix can take weeks to reach the official build.

If none of those apply, don't compile. The prebuilt vanilla server plus server_config.toml covers a normal community server — that's the other guide.

Prerequisites

Three tools. The versions depend on the codebase you're building:

Linux package-manager versions of all three are fine as long as they meet the pinned versions. On an ARM64 Mac: forks on RobustToolbox engine versions older than 267.0.0 may require the x64 .NET SDK (via Rosetta) instead of the ARM64 one.

Hardware: compiling is heavier than running. Expect the first build to want a few GB of RAM and several GB of disk for the repo and build output — and noticeably more time on shared-CPU VPSes; dedicated cores make a real difference here.

Step 1 — Clone the code

Vanilla:

git clone --branch stable https://github.com/space-wizards/space-station-14.git
cd space-station-14
python RUN_THIS.py

A plain clone gives you master — the development branch, which the official docs say not to host from. --branch stable gets you the hosting branch; build from master only for the "I need that fix now" case, knowing it can contain unfinished work. Whichever branch or fork you pick, its global.json decides the SDK.

RUN_THIS.py initialises and updates the engine submodules; it takes seconds. If it seems to flash open and close on Windows, that's normal. If it fails, the manual fallback is git submodule update --init --recursive.

For a fork, clone its repository instead — and drop --branch stable unless the fork's docs tell you to use it: most forks (Goob, Delta-V, Frontier among them) have no stable branch and build from their default branch. Most forks keep the upstream layout (clone → RUN_THIS.py → build), but not all: the separate Goob-Reforged codebase builds through its own Goobstation.Bootstrap project (the main Goob-Station repo follows the standard flow), and Einstein Engines uses its own build scripts. Einstein Engines is also the odd one out in lineage — a hard fork that no longer merges upstream directly and ports changes by hand instead, so it has drifted far from vanilla, with its own toolchain pins to match; EE's own repo has been quiet since March 2026, so if you run an EE downstream, check that downstream's pins, not EE's. Read the fork's README before touching anything, and check its global.json for the SDK it expects.

Step 2 — Build and test-run

dotnet build --configuration Release
dotnet run --project Content.Server --configuration Release

(dotnet --version, run inside the repo, should report the version global.json asks for — 10.x on upstream. A "compatible .NET SDK was not found" error means the pin and your installed SDK disagree.)

Wait for the console to report ready, then point the SS14 launcher at localhost via Direct Connect. In this dev-style run the server serves the client straight from your source tree ("Magic ACZ"), and connecting from localhost automatically grants you +HOST admin — handy for testing, dangerous in production (more below).

This run is for verifying your build works. Don't host a public server this way — package it properly:

Step 3 — Package a production server

dotnet run --project Content.Packaging server --hybrid-acz --platform linux-x64

Swap linux-x64 for win-x64, linux-arm64, win-arm64, osx-x64 or osx-arm64 to match the host. Packaging writes release/SS14.Server_linux-x64.zip — your client already bundled inside — plus a separate SS14.Client.zip you can ignore. On the host: extract the server zip, chmod +x Robust.Server (Linux/mac), run ./Robust.Server.

The flag that matters: --hybrid-acz bundles your custom client into the server package, and the server serves it to joining players' launchers over its HTTP status port (TCP 1212). Package without it and you must host the client download yourself — via [build] download_url or Robust.Cdn — or the launcher has nothing to download and nobody can connect. For a small-to-mid community, hybrid ACZ is all you need; Robust.Cdn is the documented next step for serious permanent hosts, moving build distribution off the game process.

One cost to budget for: with hybrid ACZ the server builds an in-memory copy of the client the first time a launcher asks for it, and keeps it loaded. Content-heavy forks package client zips of around 2 GB — zip size and memory use aren't the same number, but a client that size means a serious chunk of extra RAM on top of what the game itself needs. Measure your own fork if you want the exact figure. It's one more reason large forks move their client to a CDN.

(Older guides mention python Tools/package_server_build.py — that script has been removed from current codebases; Content.Packaging is the only path.)

Step 4 — Configure, go public

Configuration lives in server_config.toml next to the server binary. The essentials for a custom build:

[game]
hostname = "Your Server Name"

[hub]
advertise = true            # public listing — advertising means accepting the hub rules
tags = "rp:med,region:eu_w" # use the standard tag vocabulary (rp:low/med/high, region:eu_w, lang:en, ...)

[build]
fork_id = "your-fork-id"    # stable identifier so launchers don't re-download needlessly

Open UDP and TCP port 1212 (game netcode and the launcher's status API respectively). The default SQLite database is fine to start; busy servers switch the [database] section to PostgreSQL — the server runs its own migrations on startup.

Admin access, done safely:

• +HOST is extremely dangerous to hand out — the official docs are blunt about this. Grant it to yourself only.
• Localhost connections get +HOST automatically. On a production box where anything tunnels or forwards game traffic in a way that makes it appear local, disable that:

[console]
loginlocal = false
login_host_user = "yourname"  # persistent host grant for you instead

• promotehost yourname from the server console is temporary — it lasts while you're connected. For persistence use login_host_user above, then build real admin ranks with the in-game permissions command for everyone else.

Step 5 — Updating a custom build

This is where fork servers go to die, so make it routine:

1. Pull and rebuild. git pull, re-run python RUN_THIS.py (submodules move between versions), rebuild, re-package. Config-only changes don't need a rebuild; code and content changes do.
2. Re-check global.json after every pull. When a fork bumps its engine version, the required SDK — and the runtime on your host — can jump with it (upstream's move to .NET 10 came with engine 269).
3. If you carry your own changes on top of a fork, keep them on a branch and merge the fork's updates in — expect occasional conflicts in content files (prototypes, maps). Resolve, rebuild, test on localhost before replacing the live server.
4. Back up the server's data directory (default data/) and server_config.toml before every swap. The SQLite database (player characters, preferences, admin ranks) lives there. Switched to PostgreSQL? That database lives outside the server folder — back it up separately (pg_dump). Whether your fork persists anything of the world itself is fork-dependent — know before you assume.
5. For a serious permanent server, the official answer to update management is SS14.Watchdog — it handles updates, restarts and monitoring. (It also has a Git mode that builds from a fork repo, but the docs mark that mode unmaintained; for production they point at manifest-based updates from prebuilt packages.)

Classic failure modes

• Build fails immediately after cloning → you downloaded the ZIP or skipped RUN_THIS.py; the submodules are missing. Clone with Git and run the script.
• "A compatible .NET SDK was not found" → the repo's global.json pins a version you don't have. Install that SDK (they coexist fine).
• Builds on your PC, fails on the server → usually a missing or mismatched .NET runtime on the host, a skipped chmod +x, or a --platform that doesn't match the host.
• Players can't join your custom server → packaged without --hybrid-acz and no build.download_url or CDN configured, so the launcher has no client to download.
• Server runs but won't list on the hub, or players see it but can't connect → check TCP and UDP 1212 first (the status API and game netcode respectively — both must be open). Not that? Disabled hub.advertise or a failed client download can look identical.

Hosting the result

Self-hosting a compiled build works like self-hosting anything: an always-on machine, both 1212 ports forwarded, and you own the update routine. Custom builds also run on our SS14 servers (EU datacenter, from €3.60/mo): upload release/SS14.Server_linux-x64.zip over SFTP, extract it, chmod +x Robust.Server, start. Three things we tell every fork host:

• RAM depends on your fork, not on a table. Between hybrid ACZ holding the client in memory and wildly different content sizes per fork, the same player count can need gigabytes more on one fork than another. Start one size up from vanilla guidance, watch real usage for a week, and resize — or move the client to Robust.Cdn and reclaim that memory.
• A panel reinstall restores the standard build and removes your custom files. Keep your packaged zip (and a backup) so redeploying after a reinstall is a five-minute upload, not an emergency rebuild.
• Forks pinned to an older .NET need the matching runtime on the host — if your build won't start where the official one does, that's the first thing to check (and something we can help with).

Further reading

• Official server hosting tutorial — the canonical reference this guide builds on
• SS14 server hosting: the complete guide — setup, hardware and admin basics without compiling
• SS14 basic configuration docs — config walkthrough for servers hosted with us
• Space Station 14 on GitHub — the upstream codebase

Upstream commands and versions verified against the official Space Wizards documentation, October 2026 (.NET 10 SDK since engine 269, the Content.Packaging path, ACZ behaviour). Fork specifics come from the forks' own repositories and move fast — when a fork's README or global.json disagrees with this guide, the fork wins. Hybrid ACZ holding the client in memory follows from the RobustToolbox source; the ~2 GB client-zip figure is our own observation on OXY.Games nodes.