Starbound server config and mods

A Starbound dedicated server ships inside the game itself: starbound_server (Linux) or starbound_server.exe (Windows) sits next to the game executable, and you download it with SteamCMD using an account that owns Starbound. Its whole configuration is one JSON file, storage/starbound_server.config, written on the first start. It listens on TCP 21025, needs about 1-2 GB of memory for a small group (more with big mods such as Frackin' Universe), and stores the shared universe in storage/universe. Characters stay on each player's machine. Mods are .pak files in the mods folder, and every player needs the same ones.

How a Starbound server works#

Starbound multiplayer has two forms. Hosting from the game (or through Steam friends) runs the universe on one player's machine. A dedicated server runs it separately, with no player attached, so the universe - every planet visited, every colony, every base - exists whether or not the host is online.

What the server owns and what the client owns:

• The universe is the server's: planets, their changes, ships parked in orbit, colony deeds, and the celestial map.
• Characters are the client's: inventory, ship, quest progress and appearance are saved on each player's PC. A character can visit any server, which is why items can arrive from elsewhere.
• Mods are both: the server and every client need matching .pak files for anything that adds content.

The game's last major version is 1.4.x, and development has stopped. That means two things for a server owner: the server is stable and well understood, and the community has filled the gaps. Frackin' Universe is the big overhaul mod, and community projects such as OpenStarbound offer a modified client and server with fixes and extra features. They are separate projects with their own install steps; this guide covers the stock server, which is what most groups still run.

What persists on the server and what travels with the player

The split between server and client explains most surprises a new server owner hits, so it is worth being precise about it.

The player's ship is part of the character, not the universe. It is saved on the player's machine together with the inventory, so upgrades, decorations and storage lockers on the ship travel with them from server to server. A player who fills their ship lockers with rare ores on one server arrives on yours with all of it. If you run an economy or a progression-focused server, that is the main hole, and only a fresh-character rule (enforced socially or by mod) closes it.

Planets belong to the server. Everything built on a planet surface - bases, farms, colony houses with their tenants, mined tunnels - is stored in the universe files and stays there whether or not the builder is online. That includes damage: a griefer who digs through someone's colony on a public server leaves a permanent mark until an admin repairs it or you restore the world from a backup.

Instanced worlds are different again. Mission dungeons, the Outpost and some special locations are rebuilt from the game's assets rather than kept as player-modified worlds, so changes there are temporary. Quest and mission progress is saved with the character, which is why a player who has finished the story on another server sees it finished on yours.

The practical rules that follow:

• A universe reset does not touch characters or ships. It wipes planets and colonies only.
• A player losing their character is not something the server can fix. It lives in their own storage/player folder; point them at their local backups.
• Restoring the whole universe rolls back every planet at once. Each visited planet is its own .world file, named after its coordinates, so with the server stopped you can also copy back just one planet from a backup - slower to find, but fairer to everyone else.
• Coordinates are shared. Players exchange the coordinates of good planets, and everyone visiting the same planet sees the same world, which is what makes a dedicated server feel like a shared place rather than parallel single-player games.

Requirements and resource usage#

Starbound is light on CPU and moderate on memory. The cost comes from the number of worlds kept loaded - each player on a different planet means another world in memory - and from mods.

• CPU: each loaded world is simulated separately, so several players on several planets use several threads. One player alone is cheap.
• Disk: the game install is a few gigabytes; the universe folder grows with every planet visited, into hundreds of megabytes for a long-lived server.
• Network: modest. Latency matters more than bandwidth - see latency, jitter and packet loss.

Installing with SteamCMD#

The server is not a separate anonymous app. You download the game (app 211820) with an account that owns it:

$ steamcmd +force_install_dir /home/starbound/game +login your_steam_user \    +app_update 211820 validate +quit

Use a spare account with its own copy if you can, not the account you play on: the login is stored wherever SteamCMD runs, and Steam Guard asks for a code on first login. SteamCMD explained covers the login flow and why some games need an owned account when most do not.

The server binary sits in a platform folder:

$ cd /home/starbound/game/linux$ ./starbound_server

On Windows, run win64\starbound_server.exe. On first start the server reads the game's assets, creates storage/ in the game root, writes starbound_server.config with defaults, and begins listening. Stop it cleanly once, then edit the config.

starbound_server.config, key by key#

The file is JSON. A typical edited version:

{  "serverName": "Kluex Station",  "maxPlayers": 8,  "gameServerBind": "*",  "gameServerPort": 21025,  "allowAnonymousConnections": false,  "anonymousConnectionsAreAdmin": false,  "allowAdminCommandsFromAnyone": false,  "allowAssetsMismatch": false,  "checkAssetsDigest": false,  "maxTeamSize": 4,  "serverUsers": {    "nova": { "admin": true, "password": "change-me-long-one" },    "kai": { "admin": false, "password": "another-long-one" }  },  "bannedIPs": [],  "bannedUuids": [],  "runQueryServer": false,  "queryServerPort": 21025,  "runRconServer": false,  "rconServerPort": 21026,  "rconServerPassword": ""}

What the important keys do:

Beyond those, maxTeamSize limits party size, clearUniverseFiles and clearPlayerFiles wipe data on start (leave them false unless you mean it), and serverFidelity controls the simulation detail level - automatic is right for nearly everyone.

Accounts versus anonymous play

Starbound has no join password as such. Access control is the serverUsers block: each entry is an account name with a password and an admin flag. With allowAnonymousConnections false, only those accounts can join. Players enter the account name and password in the join dialog alongside the address.

For a public server, anonymous connections are on and moderation is by ban list; for a private one, accounts are simpler and stronger than relying on nobody guessing the address.

Asset mismatch and mod enforcement

allowAssetsMismatch and checkAssetsDigest decide what happens when a client's mods differ from the server's. The defaults are permissive, so a player without the mod pack can connect - and then sees missing items, invisible blocks, or crashes when they visit a modded planet. For a modded server, the strict combination (allowAssetsMismatch false, checkAssetsDigest true) turns that confusion into a clear refusal at the door. The catch is that every client must then match exactly, including client-only cosmetic mods, so it suits groups with a shared, fixed mod list.

Ports and connecting#

Starbound is unusual among game servers in using TCP for gameplay. A firewall rule that opens UDP only - the right choice for most games - leaves a Starbound server unreachable. Game server ports explained covers the difference.

Players join through Multiplayer, Join Server, and enter the address, port, and the account name and password if you use accounts. Steam friends can also join through the Steam overlay on servers they can see. There is no meaningful public browser for Starbound, so community servers advertise on forums and Discord - a domain name pointed at the server makes the address easier to share; see connecting a domain to a game server.

Admin commands#

Admins are accounts with "admin": true in serverUsers. Once in, an admin types /admin in chat to toggle admin mode, which unlocks the admin commands and gives creative-style powers while it is on.

Ban arguments have changed slightly across builds; /help ban on your version shows the exact form. Bans land in bannedIPs and bannedUuids in the config, so they survive restarts and can be removed by editing the file with the server stopped.

Use RCON only if you need remote administration from a tool, and only with a long password - using RCON safely explains why an open RCON port is a common way into a game server.

Mods on a Starbound server#

Starbound mods are .pak archives, sometimes loose folders, placed in the mods folder of the game root - the same on server and client.

Getting them onto a server:

1. On a client, subscribe in the Steam Workshop. Each mod downloads to steamapps/workshop/content/211820/<id>/ as contents.pak.
2. Copy each contents.pak to the server's mods folder, renaming them to something readable, such as frackinuniverse.pak - two files cannot both be called contents.pak.
3. Restart the server and watch the log for errors while assets load.

The dedicated server does not subscribe to Workshop items itself, so a Workshop update does not reach the server until you copy the new file. That is useful: you decide when to update, instead of having the server change under you. Players subscribed through the Workshop update automatically, though, so announce updates and copy the new paks the same day. Steam Workshop mods on dedicated servers goes through this pattern for other games too.

Rules that save a server:

• Big overhauls first, alone. Frackin' Universe changes so much that other mods need FU-compatible versions. Start with it alone, confirm a clean start, then add compatible mods one at a time.
• Never remove a content mod from a live universe. Planets and characters that contain the mod's blocks or items can crash or corrupt when loaded without it.
• Client-only mods (interface, music, cosmetic) do not need to be on the server unless you enforce digest checking.

Backups, updates and resets#

The whole server state is the storage folder: universe (the worlds and celestial data) plus the config. Back up storage and you can rebuild the server from a fresh install.

• Stop the server before copying `universe`. Worlds are written while loaded, and a copy taken mid-write can contain a half-saved planet.
• Back up before adding or removing mods. Removing a content mod is the commonest way to break a universe.
• Keep copies off the machine. Backups that actually restore explains why copies on the same disk do not count.

Updates are rare now. When one happens, update the server through SteamCMD at the same time as the clients, because Starbound refuses mismatched versions.

A reset - a fresh universe - is a matter of stopping the server and moving storage/universe aside. Characters are unaffected, since they live on the clients.

On RE:NODE, every game server gets SFTP and an in-browser file manager for the mods and storage folders, plus backup slots that can be scheduled, locked against rotation and restored with a button. Starbound is not in the catalogue, so treat that as what the panel offers rather than a Starbound plan.

Troubleshooting#

Nobody can connect, but the server says it is listening. The port is open for UDP only. Starbound needs TCP 21025.

Players get "Incorrect password" or "No such user". With allowAnonymousConnections false, they must enter an account from serverUsers exactly, including case.

The server crashes when someone warps to a planet. That planet contains content from a mod that is missing or outdated on the server. Check the log for the missing asset path, which names the mod.

Players see invisible blocks and missing items. Their mods differ from the server's and the asset checks are permissive. Share the exact pak list, or make the checks strict.

The config resets after editing. A JSON syntax error - a missing comma or quote. Validate the file before saving it.

The server stops after hours with no message. Usually memory. Check the graphs, and see why your game server keeps restarting.

FAQ#

Do I need to own Starbound to run a server?

The server has to be downloaded with an account that owns the game, because it ships in the game's files. Players need their own copies too.

Can players bring their characters to my server?

Yes. Characters are stored on each player's machine and work on any server. If you want a fresh-start economy, you have to ask players to make new characters; the server cannot enforce it without mods.

How many players can a Starbound server hold?

maxPlayers defaults to 8 and can be raised. Memory and CPU grow with the number of worlds loaded at once, so spread-out groups cost more than groups who play together.

Will Workshop mods download to the server automatically?

No. The dedicated server does not subscribe to Workshop items. Copy each mod's .pak into the server's mods folder and update it yourself.

Is Frackin' Universe heavy on a server?

It increases memory at start and on loaded worlds noticeably, and it slows the first start while assets load. Small groups run it comfortably with 3-4 GB.