Rust Server on Linux: the Complete Guide

Running Rust on your own Linux machine gives you full control over the files, the process and the schedule, but it also means you own every step: installing SteamCMD, keeping the server running, updating it when Facepunch ships a patch, wiping it, backing it up and noticing when it crashes. This guide walks the whole lifecycle in short sections and links to a detailed guide for each part.

Everything here matches what the Panelra agent does on real hosts, and the commands were checked against a live Rust server on Ubuntu 26.04.1. The paths follow the agent's layout under /opt/rust-servers, so you can switch to Panelra later without moving anything by hand.

What you need

Before you install anything, check the machine:

• OS: Ubuntu 22.04 or 24.04, or Debian 12, with systemd. Other Debian-based releases may work, but those are the ones to pick for a new box.
• CPU architecture: x86_64. RustDedicated is a 64-bit x86 binary.
• Memory and disk: about 12 GB of RAM and 30 GB of free disk per Rust server. Several servers on one host need that much each.
• Access: root or sudo on the machine.

SteamCMD is a 32-bit program and needs two 32-bit libraries (lib32gcc-s1, lib32stdc++6); the rest are download and archive tools. These are the packages the Panelra agent installs on a Debian or Ubuntu host:

apt-get update
apt-get install -y lib32gcc-s1 lib32stdc++6 curl wget tar

Ports and firewall

A Rust server listens on four ports by default. These are the ports the agent puts in the unit file, and the ones a running server on our test host was listening on:

RCON gives full control of the server with a single password, so do not expose 28016 to the whole internet. Allow it only from the addresses that really need it. If you run a second server on the same host, give it its own set of ports.

If the server runs but players cannot find it, work through Rust server not showing in the server list. If you cannot reach the console remotely, see Rust RCON not connecting.

The Panelra agent itself connects out to Panelra over port 443, so it needs no inbound port.

Install SteamCMD and the Rust server

SteamCMD is Valve's command line client. Download it into its own folder:

mkdir -p /opt/rust-servers/steamcmd
cd /opt/rust-servers/steamcmd
curl -sqL 'https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz' | tar zxvf -

Then download the Rust dedicated server (Steam app 258550) into a folder for this server:

/opt/rust-servers/steamcmd/steamcmd.sh +force_install_dir /opt/rust-servers/instance-1 +login anonymous +app_update 258550 validate +quit

On the very first run SteamCMD updates itself and can exit with an error. That is expected: run the same command again and it completes the download. To use the staging branch instead of the public one, add -beta staging after 258550.

Rust also expects the Steam client library in root's home. The agent creates this symlink on every install:

mkdir -p /root/.steam/sdk64
ln -sf /opt/rust-servers/steamcmd/linux64/steamclient.so /root/.steam/sdk64/steamclient.so

The full walkthrough, with checks after each step, is in How to install a Rust server on Ubuntu.

Directory layout

After the first start, an install directory looks like this (trimmed, from the test host):

/opt/rust-servers/
  steamcmd/                     SteamCMD itself
  instance-1/                   one Rust server
    RustDedicated               server binary
    RustDedicated_Data/         Unity data (managed DLLs live here)
    Bundles/                    game assets, the largest folder
    steamapps/                  Steam metadata, including the build id
    .env                        RCON password (chmod 600)
    server/
      main/                     the server identity
        cfg/server.cfg          your settings
        cfg/bans.cfg
        cfg/users.cfg
        proceduralmap.4000.1420068679.289.map
        proceduralmap.4000.1420068679.289.sav
        player.blueprints.18.db
        player.deaths.18.db
        ...

Two ideas matter here:

• The install directory holds files that SteamCMD manages. You can always download them again.
• The identity folder (server/<identity>/, set with +server.identity) holds everything that belongs to your server: the config, the map, the save and the player databases. This is the folder you wipe and the folder you back up.

The map file names contain the world size and seed, for example proceduralmap.4000.1420068679.289.map is a 4000 map with seed 1420068679.

Configure server.cfg

Rust reads server/<identity>/cfg/server.cfg on start. A minimal file, based on what the Panelra agent generates:

server.hostname "Rust Server"
server.maxplayers 100
server.worldsize 4000
server.seed 1420068679
server.saveinterval 600
server.secure 1
server.ip 0.0.0.0
rcon.web 1
server.tickrate 30
server.wipemode 1
server.printReportsToConsole true

Every ConVar a Rust server lists, with its help text and the value it had on our test server, is in the Rust server ConVar reference. server.seed, server.worldsize and server.saveinterval have their own pages.

Always use a positive seed. The agent treats a seed of 0 or below as invalid: it never writes one to server.cfg and picks a random positive seed instead. With a fixed seed the map is the same after every restart, and you decide when it changes.

Keep the RCON password out of server.cfg. The agent writes it to an environment file that only root can read, and passes it on the command line:

printf 'RCON_PASSWORD=%s\n' 'pick-a-long-random-password' > /opt/rust-servers/instance-1/.env
chmod 600 /opt/rust-servers/instance-1/.env

Run it as a systemd service

The Facepunch wiki starts the server inside screen. That works, but nothing brings it back after a crash or a reboot. A systemd unit does both. This is the unit the Panelra agent writes, with its log rotation line removed:

[Unit]
Description=Rust Server
After=network.target

[Service]
Type=simple
User=root
WorkingDirectory=/opt/rust-servers/instance-1
EnvironmentFile=/opt/rust-servers/instance-1/.env
ExecStart=/opt/rust-servers/instance-1/RustDedicated \
    -batchmode \
    -nographics \
    +server.identity main \
    +server.port 28015 \
    +server.queryport 28017 \
    +app.port 28082 \
    +rcon.port 28016 \
    +rcon.web 1 \
    +rcon.password ${RCON_PASSWORD}
StandardOutput=journal
StandardError=journal
SyslogIdentifier=rust-server
Restart=always
RestartSec=5
StartLimitInterval=0
LimitNOFILE=100000

[Install]
WantedBy=multi-user.target

Save it as /etc/systemd/system/rust-server.service, then load and start it:

systemctl daemon-reload
systemctl enable --now rust-server

Restart=always with RestartSec=5 brings the server back 5 seconds after any exit, and StartLimitInterval=0 stops systemd from giving up after several fast restarts. The systemd service guide explains every line and how to run several servers on one host.

Oxide or Carbon

Most community servers run a modding framework. You pick one, not both.

Oxide (uMod) ships as Oxide.Rust-linux.zip from the Oxide.Rust releases on GitHub. You extract it into the install directory. It adds an oxide/ folder for plugins, configs and data, puts its own Oxide.*.dll files in RustDedicated_Data/Managed and patches the game's own DLLs there. A Rust update with validate puts the vanilla game files back, so, as the Facepunch wiki says, you reinstall Oxide after every Rust update. See How to install Oxide on Linux.

Carbon ships as Carbon.Linux.Release.tar.gz from the Carbon GitHub releases. It adds a carbon/ folder, carbon.sh, libdoorstop.so and Carbon.targets. On Linux Carbon only loads through its doorstop preloader: carbon.sh sources carbon/tools/environment.sh, which sets LD_PRELOAD, and then runs RustDedicated with the same arguments. So under systemd you point ExecStart at carbon.sh instead of RustDedicated, which is exactly what the agent does:

ExecStart=/opt/rust-servers/instance-1/carbon.sh \
    -batchmode \
    ...

Starting RustDedicated directly skips the preloader and Carbon never loads. Details, including the carbon/logs folder the first boot needs, are in How to install Carbon on Linux. Panelra's plugin management installs either framework and the plugins for you.

Updates

Facepunch ships Rust updates regularly, and players on a newer client cannot join an older server. An update has to stop the server, because SteamCMD must never replace the binaries under a running process. The agent's update flow is:

1. Warn players in chat with say over RCON, at 5 minutes, 2 minutes, 1 minute and 30 seconds.
2. Save the world with server.save.
3. Stop the service and wait until it is fully down.
4. Run the same app_update 258550 validate command as the install.
5. Check the new build id and start the server.

By hand, after warning players and saving:

systemctl stop rust-server
/opt/rust-servers/steamcmd/steamcmd.sh +force_install_dir /opt/rust-servers/instance-1 +login anonymous +app_update 258550 validate +quit
grep buildid /opt/rust-servers/instance-1/steamapps/appmanifest_258550.acf
systemctl start rust-server

If you installed from a branch such as staging, add the same -beta staging flag here. The build id line tells you which Rust build is installed. If you use Oxide, extract the latest Oxide.Rust-linux.zip again before systemctl start, because validate removed its patches. If you use Carbon, confirm in the journal that it loaded after the restart. The monthly forced update also forces a wipe; the order of steps for that day is in How to update a Rust server on forced wipe day.

Wipes

A wipe removes the map, and optionally the blueprints, so the next start generates a fresh world. Facepunch forces a wipe with the monthly update on the first Thursday of each month (see the forced wipe schedule for exact dates and times); many servers also wipe weekly or every two weeks in between. Step by step: how to wipe a Rust server and how to automate wipes.

A map wipe deletes the .map and .sav files in the identity folder. A full wipe also deletes the blueprint database (player.blueprints.*.db and its -wal and -shm files). Stop the server first so nothing is written while you delete:

systemctl stop rust-server
cd /opt/rust-servers/instance-1/server/main
rm -f -- *.map *.sav
rm -f -- player.blueprints.*.db player.blueprints.*.db-wal player.blueprints.*.db-shm   # full wipe only
systemctl start rust-server

To get a new map instead of the same one, change server.seed in server.cfg to another positive number before you start. Take a backup before a wipe; it is the only way back if you wiped the wrong server.

Scheduling this by hand means cron jobs, chat warnings and remembering forced wipe day. Panelra's wipe scheduling runs weekly, monthly or forced wipe schedules with seed control and a backup before every wipe.

Backups

The game files are several gigabytes and SteamCMD can always download them again, so a backup only needs everything else: the identity folder, the .env file and your framework folder with its plugins, configs and data. The agent builds its archives with tar and excludes the large files SteamCMD installs. The same thing by hand, with the server stopped so the save files are consistent:

systemctl stop rust-server
tar --warning=no-file-changed --ignore-failed-read -czf /root/rust-backup-$(date +%F).tar.gz \
  -C /opt/rust-servers/instance-1 \
  --exclude Bundles --exclude RustDedicated_Data --exclude UnityPlayer.so \
  --exclude steamclient.so --exclude libsteam_api.so --exclude RustDedicated \
  --exclude steamapps --exclude steam_appid.txt --exclude runds.sh \
  .
systemctl start rust-server

Copy the archive off the machine. A backup on the same disk does not survive a dead disk or a deleted VM. What to include, how to schedule it and how to restore is in How to back up a Rust server on Linux. Panelra's backups cover manual, scheduled and pre-wipe backups with one-click restore.

Restarts

Many admins restart once a day to clear memory growth. The commands are plain systemd:

systemctl restart rust-server
systemctl stop rust-server
systemctl start rust-server

Before a planned restart, warn players with say over RCON and save with server.save, the same way the update flow does. Rust also has a restart <seconds> console command that counts down in game and then exits; with Restart=always, systemd starts the server again after the exit.

If the server is frozen and does not answer RCON, systemctl restart still works because systemd stops the process and kills it if it does not exit in time. How to schedule restarts by hand, with player warnings, is in Rust server restart schedule: why and how. For timed restarts with in-game countdowns, see Panelra's restart scheduling.

Monitoring and crashes

With the server under systemd, its whole console output is in the journal:

systemctl status rust-server
journalctl -u rust-server -f

Because Restart=always brings the server back within seconds, a crash can go unnoticed. systemd counts those automatic restarts, and a manual systemctl restart resets the counter. An in-game restart <seconds> countdown also adds one when it ends, so if you did not use that, a number that keeps growing means the server is dying on its own:

systemctl show rust-server -p NRestarts -p MainPID

When a crash happens, the unit journal holds the reason as a systemd line such as Main process exited, code=killed, status=9/KILL. A KILL you did not send is often the kernel's out-of-memory killer. Check the kernel log for it:

journalctl -k | grep -i "killed process"

An OOM kill means the host ran out of memory, which is the usual sign that there is not enough RAM for the map size, the player count or the plugins. Crash loops are the other thing to watch: the same crash every few minutes after an update or a new plugin. Rust server killed: out of memory shows how to confirm an OOM kill and what to change, and Rust server stuck on startup covers a server that never finishes loading.

Panelra's agent reads the same signals: it tracks NRestarts, reads the exit reason from the journal, checks the kernel log for OOM kills and ignores restarts you planned. Crashes, crash loops, a server that stops responding and a host that goes offline show up in an alerts inbox and can be posted to Discord. See server monitoring and crash alerts.

Let Panelra run it for you

Everything above is a one-time setup plus a weekly routine of updates, wipes, backups and checking logs. Panelra does all of this for you: install the agent on your Linux host with one command from the dashboard, and it installs SteamCMD and Rust, writes the systemd unit, installs Oxide or Carbon, and handles updates, wipe schedules, backups, restarts and crash alerts from the browser. It uses the same layout as this guide, under /opt/rust-servers.

curl -sL https://app.panelra.io/install | sudo AGENT_TOKEN=<your-token> bash

Free during the open beta. Pricing will be announced before the beta ends.