Rust Server erstellen: 13 Schritte, 30 Min [2026]

Rust gehört auch 2026 zu den meistgespielten Survival-Titeln auf Steam: Im 30-Tage-Durchschnitt zählt SteamCharts rund 103.730 gleichzeitige Spieler, der Allzeit-Rekord liegt bei 262.284 Concurrent Playern am 2. Januar 2025. Wer nicht auf überfüllten Community-Servern um einen Startplatz kämpfen will, richtet sich einen eigenen Rust-Server ein – mit voller Kontrolle über Wipe-Zyklus, Mods, Spieleranzahl und Adminrechte. Diese Anleitung führt in 13 Schritten durch die komplette Einrichtung eines Rust Dedicated Servers unter Linux: von SteamCMD über Firewall-Regeln und Startskript bis zu Oxide- und Carbon-Mods, Autostart per systemd, DDoS-Absicherung und automatisierten Backups. Reine Einrichtungszeit: rund 30 Minuten, Vorkenntnisse in Server-Administration sind nicht nötig.

Voraussetzungen: Was Sie für den eigenen Rust-Server brauchen

Ein Rust Dedicated Server ist deutlich hungriger als klassische Minecraft- oder Valheim-Server, weil die prozedural generierte Karte komplett im Arbeitsspeicher gehalten wird. Facepunchs eigene Server-Dokumentation nennt 12 GB freien Arbeitsspeicher als Richtwert für einen stabilen Betrieb; Hosting-Anleitungen wie die von Corrosion Hour kommen für kleine Test- oder Solo-Server auch mit 4–8 GB aus. In der Praxis hängt der tatsächliche Bedarf stark von Weltgröße und Spielerzahl ab. Die folgende Tabelle zeigt praxisnahe Richtwerte für einen Standard-Aufbau mit 4.500er-Weltgröße:

Komponente	Minimum	Empfohlen
Betriebssystem	Ubuntu 22.04 LTS / Debian 12 (64-Bit)	Ubuntu 24.04 LTS
RAM	8 GB	16 GB (ab Weltgröße 4.000+)
CPU	4 Kerne, ≥ 2,9 GHz	6–8 Kerne, ≥ 3,2 GHz Single-Thread-Leistung
Speicherplatz	10 GB frei (SSD)	20 GB+ frei (NVMe)
Netzwerk	100 MBit/s Upload	1 GBit/s, unlimitiertes Datenvolumen

Der große Unterschied zwischen Minimum und Empfehlung erklärt sich durch die Boot-Phase: Beim ersten Start und nach jedem Wipe generiert die Engine die komplette Karte neu und hält sie danach vollständig im RAM, statt sie wie andere Survival-Titel in Chunks nachzuladen. Wer knapp kalkuliert, riskiert genau in diesem Moment einen Absturz.

Bei der Wahl der Plattform lohnt sich zudem ein Blick auf den Netzwerkstandort: Für eine überwiegend deutsche oder DACH-weite Zielgruppe reduziert ein Rechenzentrum in Deutschland, Österreich oder der Schweiz die Ping-Zeiten spürbar gegenüber Standorten in Nordamerika oder Asien – ein Faktor, der bei einem PvP-lastigen Shooter wie Rust direkten Einfluss auf die Spielerfahrung hat und bei der Anbieterwahl mindestens so viel Gewicht haben sollte wie der reine Preis pro Gigabyte RAM. Zusätzlich zur Hardware brauchen Sie folgende Software-Bausteine:

SteamCMD (aktuelle Version, direkt aus den Paketquellen oder von Valve)
32-Bit-Kompatibilitätsbibliotheken (u. a. lib32gcc-s1)
screen oder tmux für persistente Terminal-Sitzungen
Root- oder Sudo-Zugriff auf den Linux-Server
Einen Steam-Client zum späteren Verbinden als Spieler (der Server selbst braucht keinen Steam-Account)

Warum überhaupt einen eigenen Rust-Server betreiben?

Auf offiziellen und großen Community-Servern bestimmen fremde Admins Wipe-Termine, Plugin-Auswahl und Regeln. Ein selbst gehosteter Server dreht dieses Verhältnis um: Sie legen Weltgröße, maximale Spieleranzahl, Wipe-Rhythmus und Mod-Stack selbst fest und behalten über RCON jederzeit die volle Kontrolle. Für Freundesgruppen, Clans oder Streamer ist das oft der einzige Weg zu einer Umgebung, die wirklich zur eigenen Spielweise passt – PvE-lastig mit Loot-Boost, PvP-Arena mit kurzen Wipe-Zyklen oder ein ruhiger Low-Pop-Server für 20 bis 30 Stammspieler.

Hinzu kommt die Modding-Freiheit: Mit Oxide oder Carbon lassen sich Kits, Clan-Systeme, Zonen-Schutz, Wirtschafts-Plugins mit eigener Shop-Währung oder komplette Progression-Overhauls nachrüsten, die auf gemieteten Standard-Paketen oft gar nicht zur Wahl stehen. Beliebte Plugin-Kategorien reichen von Raidable Bases über automatisierte Kits bis zu Anti-Cheat-Erweiterungen, die zusätzlich zum integrierten Easy Anti-Cheat greifen. Der einzige Nachteil gegenüber einem gemieteten Paket: Updates, Firewall, Absicherung und Uptime liegen komplett in eigener Verantwortung – genau das deckt diese Anleitung Schritt für Schritt ab.

Server-Varianten: Vanilla, Solo/Duo/Trio und PvE

Bevor es an die technische Einrichtung geht, lohnt sich eine Entscheidung über das Format – sie bestimmt später, welche Startparameter und Plugins überhaupt sinnvoll sind. Ein Vanilla-Server läuft mit den Standardregeln von Facepunch und braucht außer der Grundinstallation keine weiteren Anpassungen. Deutlich populärer in der Community sind Solo/Duo/Trio-Server, die die Gruppengröße künstlich auf ein, zwei oder drei Spieler pro Team begrenzen – technisch über ein Oxide- oder Carbon-Plugin wie einen Gruppen-Limiter umgesetzt, nicht über einen nativen Rust-Parameter. Das sorgt für ein ausgeglicheneres Spielfeld gegenüber organisierten Fünfer- oder Zehner-Clans und ist bei kleineren Community-Aufbauten inzwischen der De-facto-Standard.

PvE-Server deaktivieren oder entschärfen Spieler-gegen-Spieler-Kämpfe meist über ein Zonen- oder Regel-Plugin und richten sich an Communitys, die lieber gemeinsam bauen als sich gegenseitig zu raiden. Langzeit- oder „No-Wipe”-Server weichen bewusst vom monatlichen Facepunch-Rhythmus aus Schritt 12 ab und setzen auf seltenere, angekündigte Wipes, um größere Basen und Wirtschaftssysteme über Monate bestehen zu lassen. Welche Variante am Ende passt, hängt von der Zielgruppe ab – für den Einstieg ist ein einfacher Vanilla- oder Solo/Duo-Aufbau mit Standard-Wipe-Rhythmus die unkomplizierteste Wahl und lässt sich jederzeit später per Plugin erweitern, ohne die Grundinstallation neu aufzusetzen.

Eine vierte, seltener genutzte Variante sind reine Arena- oder Event-Server, die abseits der offenen Welt kleine, abgeschlossene Kampfmodi anbieten – meist als Zusatzangebot neben einem regulären Hauptserver, nicht als Ersatz dafür. Für den Einstieg in dieser Anleitung ist das jedoch eine Ausbaustufe für später: Erst sollte die Grundinstallation stabil laufen, bevor zusätzliche Spielmodi aufgesetzt werden.

Schritt 1: Server-Umgebung und Benutzer vorbereiten

Bevor die eigentliche Installation beginnt, sollte das System aktuell sein und ein eigener, nicht-privilegierter Benutzer für den Betrieb angelegt werden. Das verhindert, dass ein kompromittiertes Spiel-Binary mit Root-Rechten laufen kann – ein Standard-Sicherheitsprinzip bei jedem Game-Server-Setup und besonders auf einer Sicherheits- und Datenschutz-Seite wie dieser keine Randnotiz, sondern der erste Schritt.

sudo apt update && sudo apt upgrade -y
sudo useradd -m -s /bin/bash rustserver
sudo passwd rustserver
su - rustserver

Ab hier arbeiten Sie als Benutzer rustserver weiter. Legen Sie direkt ein Verzeichnis für die Installationsdateien an, zum Beispiel ~/rust-server. Alle folgenden Schritte gehen davon aus, dass dieser Nutzer sowohl SteamCMD als auch den späteren systemd-Dienst betreibt – niemals als root.

Schritt 2: SteamCMD installieren

SteamCMD ist Valves Kommandozeilen-Tool zum Herunterladen von Dedicated-Server-Dateien. Auf Ubuntu und Debian braucht es zusätzlich 32-Bit-Bibliotheken, da Teile des Steam-Unterbaus weiterhin als 32-Bit-Binary ausgeliefert werden.

sudo dpkg --add-architecture i386
sudo add-apt-repository multiverse
sudo apt update
sudo apt install lib32gcc-s1 steamcmd -y

Auf Debian 12 (Bookworm) heißt der entsprechende Schritt statt multiverse das Aktivieren der non-free-Paketquellen, bevor apt install steamcmd ausgeführt wird. Bei der ersten Ausführung fragt SteamCMD die Steam-Lizenzbedingungen ab – mit Enter bestätigen. Für die Server-Installation selbst ist kein persönlicher Steam-Account nötig: Sie erfolgt über einen anonymen Login, da Facepunch die Dateien öffentlich zugänglich macht. Das unterscheidet Rust von einigen anderen Titeln, bei denen ein Account, der das Spiel besitzt, zwingend erforderlich ist.

Schritt 3: Rust Dedicated Server herunterladen

Der Rust Dedicated Server hat auf Steam eine eigene App-ID: 258550, getrennt vom Client-Spiel (App-ID 252490). Mit SteamCMD und anonymem Login laden Sie die Dateien direkt in das vorbereitete Verzeichnis:

mkdir -p ~/rust-server
steamcmd +force_install_dir ~/rust-server +login anonymous +app_update 258550 validate +quit

Je nach Internetanbindung dauert der erste Download mehrere Minuten, da neben dem Binary auch alle Map- und Asset-Daten heruntergeladen werden. Wichtig: Wiederholen Sie denselben Befehl später für jedes Update – validate prüft dabei automatisch auf beschädigte Dateien und lädt nur fehlende oder veränderte Anteile nach. Wer eine Testversion vorab ausprobieren möchte, kann mit dem Zusatz -beta staging oder -beta aux01 auf die jeweiligen Vorabversions-Branches wechseln, bevor ein Update auf den Hauptzweig übernommen wird. Das ist besonders nach großen monatlichen Rust-Updates sinnvoll, um Plugin-Kompatibilität vorab zu prüfen.

Schritt 4: Ports öffnen und Firewall konfigurieren

Rust nutzt mehrere Ports für Spielverbindung, Server-Browser-Abfragen und Fernadministration. Der Query-Port darf laut offizieller Facepunch-Dokumentation niemals identisch mit dem Spielport sein – das ist einer der häufigsten Einrichtungsfehler überhaupt.

Port	Protokoll	Zweck
28015	UDP	Spielport – Verbindung der Clients zum Server
28016	UDP	Query-Port – Server-Browser-Sichtbarkeit, standardmäßig Spielport + 1
28017	TCP	RCON – Fernadministration und WebRCON
28082	TCP	Rust+ Companion-App (optional, App-Port)

Unter Ubuntu/Debian mit ufw öffnen Sie die benötigten Ports so:

sudo ufw allow 28015/udp
sudo ufw allow 28016/udp
sudo ufw allow 28017/tcp
sudo ufw enable

Läuft der Server bei einem Cloud-Anbieter, reicht die lokale Firewall allein nicht aus – zusätzlich muss die Security Group oder das Cloud-Firewall-Profil im jeweiligen Anbieter-Dashboard dieselben Ports freigeben. Das ist die zweithäufigste Ursache dafür, dass eine technisch korrekt gestartete Installation von außen nicht erreichbar ist. Notieren Sie sich beide Stellen (lokale Firewall und Cloud-Panel), bevor Sie mit der Fehlersuche beginnen.

Bei den meisten deutschen und europäischen Cloud-Anbietern heißt die zweite Firewall-Ebene „Cloud Firewall”, „Security Group” oder schlicht „Netzwerkregeln” im Kundenpanel – die genaue Bezeichnung unterscheidet sich, das Prinzip bleibt aber gleich: eingehender Traffic muss explizit erlaubt werden, bevor er überhaupt beim Betriebssystem und dessen lokaler ufw-Konfiguration ankommt. Wer beide Ebenen verwechselt, öffnet häufig nur eine davon und wundert sich anschließend, warum der Server trotz „richtiger” Firewall-Regel nicht erreichbar ist.

Schritt 5: Startskript erstellen

Statt alle Parameter jedes Mal manuell einzutippen, bündelt ein Startskript die komplette Konfiguration. Legen Sie im Installationsverzeichnis eine Datei start.sh an:

#!/bin/bash
cd "$(dirname "$0")"
./RustDedicated -batchmode -nographics \
  +server.hostname "Mein Rust Server" \
  +server.port 28015 \
  +server.queryport 28016 \
  +server.identity "server1" \
  +server.level "Procedural Map" \
  +server.seed 12345 \
  +server.worldsize 4500 \
  +server.maxplayers 100 \
  +server.saveinterval 300 \
  +rcon.port 28017 \
  +rcon.password "CHANGE_ME_SICHERES_PASSWORT" \
  +rcon.web 1 \
  +server.secure 1

chmod +x start.sh

Ersetzen Sie CHANGE_ME_SICHERES_PASSWORT unbedingt durch ein langes, einzigartiges Passwort – ein offener RCON-Port mit Standardpasswort ist ein beliebtes Einfallstor, um komplette Installationen zu übernehmen oder zu löschen. Ein Passwort-Manager mit Zufallsgenerator ist hier die richtige Wahl, kein selbst ausgedachtes Wort.

Schritt 6: Karten- und Basiskonfiguration festlegen

Drei Parameter bestimmen die Spielwelt: server.seed (ein Wert zwischen 0 und 2.147.483.647, der die prozedurale Generierung steuert), server.level ("Procedural Map" für eine zufällig generierte Welt, alternativ feste Karten wie Barren oder eigene .map-Dateien, etwa von Community-Bibliotheken wie RustMaps) und server.worldsize (Kantenlänge der Karte, sinnvoller Bereich 1.000 bis 6.000). Bleiben Seed, Level und Worldsize identisch, generiert die Engine bei jedem Neustart exakt dieselbe Karte – praktisch, um vor dem eigentlichen Wipe-Tag auf einem Testsystem dieselbe Welt mit neuen Plugins durchzuprobieren, ohne Überraschungen im Livebetrieb zu riskieren.

server.maxplayers sollte zur Hardware passen: 50 bis 100 Spieler laufen auf der empfohlenen Konfiguration aus der Tabelle oben stabil, für 150 bis 200+ Spieler braucht es spürbar mehr CPU-Takt und RAM. Größere Weltgrößen verlängern zudem die Generierungszeit beim Boot spürbar – eine 6.000er-Karte kann auf schwächerer Hardware mehrere Minuten länger brauchen als eine 3.000er. Alle Einstellungen lassen sich alternativ dauerhaft in einer server.cfg im Ordner identity/server1/cfg/ hinterlegen; Werte, die zur Laufzeit per RCON geändert werden, überschreiben die Startparameter, bis das System neu startet.

Schritt 7: Server zum ersten Mal starten

Starten Sie die Installation in einer screen-Sitzung, damit der Prozess auch nach dem Trennen der SSH-Verbindung weiterläuft:

screen -S rust ./start.sh

Ein erfolgreicher Start durchläuft mehrere Ladephasen und endet mit einer Zeile, die den Betrieb als bereit markiert. Eine typische Ausgabe sieht so aus:

Loading Rust Server Assemblies...
Filename: linux/RustDedicated
[Server] server.compression [Enabled]
[Boot] Delaying save to next frame
Generating new map [12345/4500]
Server startup complete
Listening on 0.0.0.0:28015

Verlassen Sie die Sitzung mit Strg+A, dann D, ohne den Prozess zu beenden. Mit screen -r rust steigen Sie jederzeit wieder in die laufende Konsole ein. Bei einer neuen, großen Weltgröße kann die erste Kartengenerierung je nach CPU mehrere Minuten dauern – ein scheinbar „eingefrorenes” Terminal ohne neue Log-Zeilen ist in dieser Phase normal und kein Fehler.

Schritt 8: Verbinden und Admin-Rechte vergeben

Zum Verbinden öffnen Sie im Rust-Client die Entwicklerkonsole (F1) und geben ein:

client.connect IHRE-SERVER-IP:28015

Um sich selbst Admin-Rechte zu geben, brauchen Sie Ihre SteamID64 (über Dienste wie steamid.io ermittelbar) und tragen sie direkt in der Konsole oder per RCON ein:

ownerid IHRE_STEAMID64 "Ihr Anzeigename"
moderatorid IHRE_STEAMID64 "Ihr Anzeigename"

ownerid vergibt vollen Zugriff auf alle Admin-Befehle (inklusive noclip, Godmode und Verwaltung), moderatorid beschränkt sich auf Moderationsbefehle wie Kick und Ban. Für Teams mit mehreren Admins empfiehlt sich diese Abstufung, statt jedem vollen Owner-Zugriff zu geben – ein Prinzip minimaler Rechtevergabe, das sich aus der klassischen IT-Sicherheit eins zu eins auf Gaming-Infrastruktur übertragen lässt.

Schritt 9: RCON einrichten und fernsteuern

Mit +rcon.web 1 aus dem Startskript ist WebRCON aktiv – eine browserbasierte Konsole, erreichbar über den in rcon.port festgelegten Port (in diesem Beispiel 28017) und das gesetzte rcon.password. Alternativ funktionieren dedizierte RCON-Clients wie RustAdmin oder BeetleRCon mit denselben Zugangsdaten. Über RCON lassen sich Befehle ausführen, ohne die SSH-Sitzung offen zu halten:

status
say "Serverneustart in 5 Minuten"
kick "Spielername" "Grund"
banid 12345678901234567 "Spielername" "Grund"
server.save

Da RCON vollen administrativen Zugriff erlaubt, sollte Port 28017 nur für vertrauenswürdige IP-Adressen freigegeben werden, sofern der Cloud-Anbieter IP-Whitelisting unterstützt – ein offener RCON-Port im gesamten Internet ist ein unnötiges Risiko, das im Sicherheitskapitel weiter unten noch vertieft wird.

Viele Admin-Teams verknüpfen RCON zusätzlich mit einem Discord-Webhook über ein passendes Oxide- oder Carbon-Plugin, sodass Kick-, Ban- und Absturz-Ereignisse automatisch in einem privaten Kanal landen, statt die WebRCON-Konsole dauerhaft im Blick behalten zu müssen. Für kleinere Teams reicht das oft völlig aus und ersetzt ein separates Monitoring-Tool in der Anfangsphase.

Schritt 10: Autostart mit systemd einrichten

Ein manuell in screen gestarteter Prozess übersteht keinen Neustart des Hosts. Ein systemd-Dienst startet die Installation automatisch beim Booten und neu, falls der Prozess abstürzt. Legen Sie dazu als Root /etc/systemd/system/rust-server.service an:

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

[Service]
User=rustserver
WorkingDirectory=/home/rustserver/rust-server
ExecStart=/home/rustserver/rust-server/start.sh
Restart=on-failure
RestartSec=10
LimitNOFILE=100000

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now rust-server.service
journalctl -u rust-server -f

journalctl -u rust-server -f zeigt die Ausgabe live an – praktisch, um den Boot-Vorgang zu beobachten, ohne eine screen-Sitzung zu benötigen. Mit systemctl restart rust-server lässt sich der Dienst danach jederzeit sauber neu starten, etwa nach einem Update. Restart=on-failure sorgt zusätzlich dafür, dass ein abgestürzter Prozess automatisch nach zehn Sekunden neu hochfährt, statt bis zur nächsten manuellen Prüfung offline zu bleiben.

Schritt 11: Modding mit Oxide oder Carbon

Für Kits, Clan-Systeme oder Wirtschafts-Plugins führt kein Weg an einem Modding-Framework vorbei. 2026 stehen dafür zwei Optionen zur Wahl, die sich beide direkt in das Installationsverzeichnis kopieren lassen:

Kriterium	Oxide (uMod)	Carbon
Status 2026	Wartungsmodus, aber bei jedem Rust-Update weiter aktualisiert	Aktive Weiterentwicklung, stark wachsende Nutzerbasis
Plugin-Bibliothek	Größte verfügbare Sammlung, über Jahre gewachsen	Nahezu vollständige Kompatibilität zu Oxide-Plugins in 2026
Performance	Referenzwert	Laut Benchmarks von Space Node 30–40 % schnellerer Boot
Installation	Release-Archiv in Server-Root entpacken	Release-Archiv plus Loader in Server-Root entpacken

Für Oxide laden Sie das aktuelle Linux-Release von der offiziellen Projektseite herunter und entpacken das Archiv direkt in das Installationsverzeichnis – die Installation ergänzt automatisch die notwendigen Harmony- und Oxide-Ordner. Nach einem Neustart zeigt die Konsole beim Boot zusätzliche Oxide-Zeilen an, ein Zeichen, dass das Framework korrekt geladen wurde. Carbon wird ähnlich installiert: Release-Archiv vom offiziellen CarbonCommunity-GitHub herunterladen, in den Server-Root entpacken und den mitgelieferten Loader-Mechanismus aktivieren; ein Konsolenbefehl wie c.version bestätigt danach die erfolgreiche Installation.

Beide Frameworks gleichzeitig zu installieren, führt zu Konflikten – ein Aufbau läuft entweder mit Oxide oder mit Carbon, nicht mit beiden parallel. Wer bereits eine große Plugin-Sammlung von einem alten Oxide-Setup mitbringt, sollte vor dem Wechsel zu Carbon bei den wichtigsten Plugin-Autoren prüfen, ob deren Code offiziell als kompatibel gelistet ist, auch wenn die Parität 2026 laut Community-Benchmarks bei nahezu 100 % liegt.

Typische Einstiegs-Plugins decken meist dieselben Grundbedürfnisse ab, unabhängig vom gewählten Framework: ein Kits-Plugin für Start- und Zeit-Ausrüstung, ein Economics- oder Shop-Plugin für eine serverinterne Wirtschaft, ein Clans-Plugin für Team-Verwaltung jenseits der nativen Rust-Teams, ein Zonen-Manager für geschützte Bau- oder PvE-Bereiche sowie ein Vanish-Plugin, mit dem Admins unsichtbar moderieren können, ohne den Spielfluss zu stören. Alle diese Kategorien existieren sowohl für Oxide als auch für Carbon; welches konkrete Plugin am Ende installiert wird, hängt von der gewünschten Server-Variante aus dem Kapitel weiter oben ab.

Ein praktischer Hinweis für den Einstieg: Nicht alle Plugins auf einmal installieren, sondern einzeln nacheinander mit Neustart und kurzem Funktionstest. Bei Konflikten zwischen mehreren gleichzeitig neu installierten Plugins lässt sich der Übeltäter sonst nur mühsam per Ausschlussverfahren finden, während ein Plugin nach dem anderen die Fehlersuche im Zweifel auf eine einzige Log-Zeile reduziert.

Schritt 12: Wipe-Zyklus und Updates automatisieren

Facepunch erzwingt auf allen offiziellen Servern einen monatlichen Wipe am ersten Donnerstag des Monats um 19:00 UTC, gekoppelt an das monatliche Content-Update; dabei werden sowohl Karte als auch Blueprints zurückgesetzt (Quelle: Rust Wipe Schedule). Die meisten Community-Betreiber übernehmen diesen Rhythmus, weil ein Großteil der Spielerbasis sich danach richtet und aktiv nach frisch gewipten Karten sucht; zusätzliche Zwischen-Wipes sind reine Betreiber-Entscheidung. Ein einfaches Wipe-Skript löscht die Speicherdateien der aktuellen Identity und aktualisiert vor dem Neustart automatisch die Installation:

#!/bin/bash
cd /home/rustserver/rust-server
systemctl stop rust-server
steamcmd +force_install_dir /home/rustserver/rust-server +login anonymous +app_update 258550 validate +quit
rm -f server/server1/*.sav*
rm -f server/server1/*.map
systemctl start rust-server

Über crontab -e lässt sich dieses Skript automatisch am ersten Donnerstag im Monat ausführen. Da Cron keine native „erster Donnerstag”-Syntax kennt, prüft ein zusätzlicher Tages-Check innerhalb des Skripts, ob der aktuelle Tag tatsächlich der erste Donnerstag ist, bevor der Wipe ausgeführt wird. Kündigen Sie Wipe-Termine idealerweise vorher über say per RCON oder einen verknüpften Discord-Webhook an, damit Spieler nicht mitten in einem Firefight aus der Welt geworfen werden.

Direkt nach einem angekündigten Wipe ist mit einem deutlichen Andrang zu rechnen, da viele Spieler gezielt frisch gewipte Server suchen und sich in den ersten Stunden gleichzeitig verbinden. Wer server.maxplayers knapp an der Grenze der eigenen Hardware konfiguriert hat, sollte an Wipe-Tagen die CPU- und RAM-Auslastung besonders im Blick behalten, etwa per htop in einer zweiten SSH-Sitzung, um bei Bedarf frühzeitig gegenzusteuern statt erst nach den ersten Beschwerden im Discord zu reagieren.

Schritt 13: Backups automatisieren

Vor jedem Update, jedem Plugin-Wechsel und jedem Wipe sollte automatisch ein Backup entstehen – gerade Oxide- und Carbon-Konfigurationen sind nach einem missglückten Update schnell verloren. Ein Cron-Job mit tar reicht für die meisten Setups aus:

#!/bin/bash
DATUM=$(date +%Y%m%d-%H%M)
BACKUP_DIR=/home/rustserver/backups
mkdir -p "$BACKUP_DIR"
tar -czf "$BACKUP_DIR/rust-backup-$DATUM.tar.gz" \
  /home/rustserver/rust-server/server \
  /home/rustserver/rust-server/oxide \
  /home/rustserver/rust-server/carbon 2>/dev/null
find "$BACKUP_DIR" -name "rust-backup-*.tar.gz" -mtime +14 -delete

Die letzte Zeile löscht automatisch Backups, die älter als 14 Tage sind, damit der Speicherplatz nicht unkontrolliert wächst. Für produktive Systeme empfiehlt es sich, die erzeugten .tar.gz-Dateien zusätzlich per rsync oder einem Cloud-Speicher-Client auf ein zweites System zu spiegeln – ein lokales Backup schützt nicht vor einem Totalausfall des Hosts, etwa bei einem Hardware-Defekt beim Provider.

Sicherheit und DDoS-Schutz für den eigenen Server

Öffentliche Spiele-Server sind ein realistisches Angriffsziel – gerade in Rust, wo Konkurrenz zwischen Clans oder Frust nach einem verlorenen Raid gelegentlich in DDoS-Angriffe gegen die IP-Adresse des Gegners umschlägt. Wer selbst hostet, trägt dieses Risiko anders als bei einem spezialisierten Gameserver-Hoster meist komplett selbst, da generische VPS- und Root-Server-Angebote DDoS-Schutz häufig nicht automatisch inkludieren. Vor der Ports-Freigabe aus Schritt 4 lohnt sich deshalb ein Blick in die Tarifdetails des eigenen Cloud-Anbieters: Manche bieten einen einfachen Basis-Schutz gegen volumetrische Angriffe optional oder sogar kostenlos an, andere verlangen ein separates Upgrade oder einen vorgeschalteten Reverse-Proxy-Dienst.

Unabhängig vom Anbieter gehören diese Grundmaßnahmen zu jedem sicheren Setup dazu:

SSH ausschließlich per Public-Key-Authentifizierung: Passwort-Login deaktivieren, root-Login per SSH sperren.
Brute-Force-Schutz: fail2ban installieren oder zumindest die Verbindungsrate begrenzen, zum Beispiel mit sudo ufw limit ssh.
RCON strikt isolieren: Port 28017 nur für bekannte Admin-IPs freigeben, niemals für „0.0.0.0″ öffnen.
Regelmäßige Updates: Sowohl das Betriebssystem (apt upgrade) als auch die Installation selbst (Schritt 3) zeitnah nach jedem Patch aktualisieren – veraltete Stände sind ein bekanntes Einfallstor.
Getrennte Zugangsdaten: RCON-Passwort, SSH-Schlüssel und ein eventueller Datenbank-Zugang für Wirtschafts-Plugins sollten unabhängig voneinander rotierbar sein.

Diese Maßnahmen ersetzen keinen dedizierten DDoS-Schutz auf Netzwerkebene, reduzieren aber die Angriffsfläche für die deutlich häufigeren Übernahmeversuche über RCON oder SSH erheblich – und die kosten im Gegensatz zu einem Anti-DDoS-Tarif nichts extra.

Auch das Betriebssystem selbst verdient nach der Ersteinrichtung noch etwas Pflege: unattended-upgrades für sicherheitsrelevante Paketaktualisierungen einrichten, nicht benötigte Dienste auf dem Host deaktivieren und den SSH-Standardport nur dann ändern, wenn das restliche Monitoring darauf eingestellt ist – reine „Security by Obscurity” ersetzt keine der oben genannten Maßnahmen, kann sie aber sinnvoll ergänzen. Wer zusätzlich eine Zwei-Faktor-Authentifizierung für den SSH-Zugang einrichtet, etwa über ein TOTP-PAM-Modul, schließt auch das Risiko eines gestohlenen privaten Schlüssels weitgehend aus.

Ein regelmäßiger Blick in die Logs rundet die Absicherung ab: journalctl -u rust-server zeigt ungewöhnliche Verbindungsmuster oder wiederholte RCON-Login-Versuche, während /var/log/auth.log fehlgeschlagene SSH-Anmeldungen protokolliert. Wer diese beiden Quellen nach der Ersteinrichtung einmal überfliegt und danach in ein einfaches Log-Monitoring (etwa per logwatch oder einem täglichen Cron-Report) überführt, bemerkt Auffälligkeiten meist Tage bevor sie zu einem echten Problem werden.

Server mieten oder selbst hosten: Der Vergleich

Wer die Hardware-Anforderungen aus Schritt 1 und den Aufwand aus den Kapiteln zu Sicherheit und Backups scheut, kann alternativ ein fertiges Mietpaket bei einem Hosting-Anbieter buchen. Beim deutschen Anbieter ZAP-Hosting starten Rust-Server-Mietpakete bei 8,64 € pro Monat für kleinere Slot-Konfigurationen; größere Pakete mit mehr Slots und RAM-Boost kosten entsprechend mehr. Die folgende Tabelle stellt beide Wege gegenüber:

Kriterium	Eigener VPS/Root-Server	Gemietetes Mietpaket
Kosten	Abhängig vom Cloud-Anbieter, meist nach RAM/CPU einzeln kalkuliert	Ab 8,64 €/Monat (ZAP-Hosting), skaliert mit Slots
Kontrolle	Vollständig – Root-Zugriff, freie Wahl bei Oxide/Carbon	Meist auf ein Anbieter-Panel beschränkt
DDoS-Schutz	Selten inklusive, muss aktiv dazugebucht werden	Bei den meisten Gameserver-Hostern im Preis enthalten
Wartungsaufwand	Updates, Firewall, Backups komplett in Eigenregie	Anbieter übernimmt die Basisinfrastruktur
Setup-Zeit	Rund 30 Minuten nach dieser Anleitung	Wenige Minuten über das Anbieter-Panel

Für einen Full-Pop-Aufbau mit 150+ Spielern und mehreren aktiven Plugins amortisiert sich ein leistungsstarker eigener VPS häufig schneller als ein vergleichbares Mietpaket, gerade über mehrere Monate gerechnet. Für den ersten eigenen Versuch oder wenn Zeit für Wartung fehlt, ist ein Mietpaket mit inkludiertem DDoS-Schutz und Support dagegen oft der pragmatischere Einstieg – die technischen Grundlagen aus dieser Anleitung helfen in beiden Fällen, weil auch gemietete Pakete meist Zugriff auf Start-Parameter, RCON und Mod-Ordner erlauben.

Ein gangbarer Mittelweg für wachsende Communitys: mit einem günstigen Mietpaket starten, um die eigene Spielerbasis ohne großes Risiko aufzubauen, und erst bei konstant hoher Auslastung auf einen selbst verwalteten Root-Server umziehen. Die in dieser Anleitung beschriebenen Startparameter, die Karten-Konfiguration aus Schritt 6 und die Plugin-Struktur aus Schritt 11 lassen sich dabei nahezu unverändert auf die neue Umgebung übertragen, sodass ein späterer Umzug keinen kompletten Neuaufbau der Konfiguration erfordert.

Häufige Fehler beim Setup

Diese Stolperfallen tauchen in Community-Foren und Support-Tickets immer wieder auf:

Query-Port identisch mit Spielport: Facepunch erlaubt das technisch nicht – der Prozess startet zwar, taucht aber nicht in der öffentlichen Serverliste auf.
RCON-Passwort im Klartext committed: Wird das Startskript in ein öffentliches Git-Repository hochgeladen, ist das Passwort sofort kompromittiert – Installationen können dann komplett gelöscht werden.
Firewall nur lokal geöffnet: ufw-Regeln allein reichen bei Cloud-Servern nicht; ohne passende Security-Group-Regel bleibt alles von außen unerreichbar.
server.secure deaktiviert: Ohne aktives Easy Anti-Cheat verweigern viele Clients die Verbindung oder der Eintrag wird als unsicher markiert.
Zu große Weltgröße auf zu schwacher Hardware: Eine Worldsize von 6.000 auf einem 8-GB-System führt zu Out-of-Memory-Abstürzen direkt beim Boot.
Oxide und Carbon gleichzeitig installiert: Beide Frameworks greifen in dieselben Prozesse ein – der Start schlägt dann fehl oder das Verhalten wird instabil.
Kein Autostart konfiguriert: Ohne systemd-Dienst bleibt alles nach einem Host-Neustart oder Absturz einfach offline, oft stundenlang unbemerkt.

Fehlerbehebung: Die häufigsten Probleme und Lösungen

Falls die Installation nach der Einrichtung nicht wie erwartet läuft, helfen diese Prüfschritte:

Eintrag erscheint nicht in der Serverliste: Query-Port prüfen (muss vom Spielport abweichen), Firewall- und Router-/NAT-Weiterleitung kontrollieren.
„Connection Failed” beim Client: IP und Spielport erneut prüfen, testen ob Port 28015/UDP tatsächlich extern erreichbar ist, server.secure muss aktiv sein.
Absturz beim Boot mit Speicherfehler: RAM reicht für die gewählte Weltgröße nicht aus – server.worldsize reduzieren oder Arbeitsspeicher aufstocken.
RCON verbindet nicht: rcon.port und rcon.password im Startskript mit den Werten im RCON-Tool abgleichen, TCP-Port in der Firewall freigeben.
Oxide-Plugins laden nicht mehr: Nach einem Rust-Update ist meist die Oxide-Version veraltet – aktuelles Release erneut in den Server-Root entpacken.
Carbon meldet eine inkompatible Version: Carbon-Builds folgen Rust-Patches oft mit wenigen Tagen Verzug – kurz auf ein Update warten oder übergangsweise auf Oxide wechseln.
SteamCMD bricht mit Statusfehler ab: +app_update 258550 validate erneut ausführen und freien Festplattenspeicher prüfen – ein häufiger Auslöser für abgebrochene Downloads.
Nach dem Wipe sind alte Strukturen noch sichtbar: Meist wurden nicht alle .sav– und .map-Dateien der aktuellen Identity gelöscht, oder das Wipe-Skript zeigt auf den falschen Ordner.
systemd-Dienst startet nicht: Pfade und den User-Eintrag in der Unit-Datei prüfen, Details liefert journalctl -u rust-server -e.
Hohe Latenz trotz guter Hardware: Anzahl aktiver Plugins reduzieren, Save-Interval prüfen und die Netzwerkanbindung des Hosts testen – oft liegt es nicht an der Rust-Installation selbst, sondern am Provider-Uplink.

Profi-Tipps für einen stabilen Rust-Server

Wer eine Installation dauerhaft und mit wachsender Community betreiben will, profitiert von einigen Praktiken, die über die reine Grundeinrichtung hinausgehen. Ein zweites, identisch konfiguriertes Testsystem mit demselben Seed und derselben Worldsize erlaubt es, neue Plugin-Versionen oder Konfigurationsänderungen vor dem eigentlichen Wipe-Tag risikofrei zu testen, statt den Livebetrieb zu gefährden. NVMe-Speicher verkürzt die Kartengenerierung bei großen Weltgrößen spürbar gegenüber klassischen SSDs – bei Worldsize 4.500 oder größer ein messbarer Unterschied beim Boot nach jedem Wipe.

Externes Monitoring über Tools, die den WebRCON-Port abfragen, oder öffentliche Tracker wie BattleMetrics benachrichtigen Admin-Teams frühzeitig bei einem Absturz, statt dass Spieler den Ausfall zuerst im Discord melden. Log-Rotation für die RustDedicated-Logs verhindert, dass die Festplatte über Monate hinweg volläuft – ein einfacher logrotate-Eintrag reicht dafür meist aus. Bei stark plugin-lastigen Setups lohnt sich der Wechsel zu Carbon wegen der Performance-Vorteile beim Boot, vorausgesetzt alle eingesetzten Plugins unterstützen das Framework bereits. Und schließlich: Ein Wipe-Rhythmus, der sich am offiziellen Facepunch-Termin orientiert, erleichtert es neuen Spielern, den eigenen Server überhaupt erst zu finden, weil viele aktiv nach frisch gewipten Welten an genau diesem Tag suchen.

Checkliste für die ersten 24 Stunden

Nach dem ersten erfolgreichen Boot ist die Arbeit nicht ganz abgeschlossen – die folgenden Punkte sollten innerhalb des ersten Tages geprüft werden, bevor größere Spielerzahlen dazukommen:

Sichtbarkeit testen: Taucht der Eintrag im offiziellen Rust-Server-Browser sowie bei BattleMetrics auf? Falls nicht, zurück zu Schritt 4 und Query-Port sowie Firewall-Regeln prüfen.
EAC-Status kontrollieren: Ein Testclient sollte sich ohne Warnhinweis zu unsicheren Servern verbinden können.
RCON-Zugriff verifizieren: Von einer Admin-IP aus per WebRCON oder RustAdmin einloggen und einen harmlosen Befehl wie status ausführen.
Backup-Job testen: Das Skript aus Schritt 13 einmal manuell auslaufen lassen und die erzeugte .tar.gz-Datei stichprobenartig entpacken.
systemd-Neustart simulieren: Mit sudo systemctl restart rust-server prüfen, ob der Dienst zuverlässig wieder hochfährt.
Wipe-Termin eintragen: Den nächsten ersten Donnerstag im Kalender oder Cron-Job hinterlegen und Spielern frühzeitig kommunizieren.

Erst wenn alle sechs Punkte bestätigt sind, sollte der Server-Name aktiv in Discord-Communitys oder Server-Listen beworben werden – nichts vertreibt neue Spieler schneller als ein Eintrag, der offline geht, sobald die ersten zehn Personen gleichzeitig verbunden sind.

Sinnvoll ist außerdem ein kurzer Testlauf mit zwei oder drei Freunden, bevor die Installation öffentlich beworben wird: Gemeinsam einloggen, ein paar Ressourcen abbauen, eine Basis anlegen und dabei gezielt Admin-Befehle wie kick und banid aus Schritt 9 einmal durchspielen. Ein solcher Trockenlauf deckt erfahrungsgemäß mehr praktische Kinderkrankheiten auf als jede Checkliste allein – von falsch gesetzten Berechtigungen bis zu Plugins, die sich gegenseitig stören.

Komplettes Beispiel-Setup zum Nachbauen

Die folgende Zusammenfassung bündelt die Schritte 1 bis 5 sowie 10 in der richtigen Reihenfolge als durchgehendes Setup, das sich direkt auf einem frischen Ubuntu-22.04-System nachbauen lässt:

# 1-2: System vorbereiten und SteamCMD installieren
sudo apt update && sudo apt upgrade -y
sudo useradd -m -s /bin/bash rustserver
sudo dpkg --add-architecture i386
sudo add-apt-repository multiverse
sudo apt update
sudo apt install lib32gcc-s1 steamcmd screen -y

# 3: Als rustserver-Nutzer die Dateien herunterladen
su - rustserver
mkdir -p ~/rust-server
steamcmd +force_install_dir ~/rust-server +login anonymous +app_update 258550 validate +quit

# 4: Firewall (als root/sudo-Nutzer)
sudo ufw allow 28015/udp
sudo ufw allow 28016/udp
sudo ufw allow 28017/tcp
sudo ufw limit ssh
sudo ufw enable

# 5-6: Startskript mit Basis- und Kartenkonfiguration
cat > ~/rust-server/start.sh << 'EOF'
#!/bin/bash
cd "$(dirname "$0")"
./RustDedicated -batchmode -nographics \
  +server.hostname "Mein Rust Server" \
  +server.port 28015 \
  +server.queryport 28016 \
  +server.identity "server1" \
  +server.level "Procedural Map" \
  +server.seed 12345 \
  +server.worldsize 4500 \
  +server.maxplayers 100 \
  +server.saveinterval 300 \
  +rcon.port 28017 \
  +rcon.password "CHANGE_ME_SICHERES_PASSWORT" \
  +rcon.web 1 \
  +server.secure 1
EOF
chmod +x ~/rust-server/start.sh

# 10: Autostart per systemd (als root/sudo-Nutzer)
sudo tee /etc/systemd/system/rust-server.service << 'EOF'
[Unit]
Description=Rust Dedicated Server
After=network.target

[Service]
User=rustserver
WorkingDirectory=/home/rustserver/rust-server
ExecStart=/home/rustserver/rust-server/start.sh
Restart=on-failure
RestartSec=10
LimitNOFILE=100000

[Install]
WantedBy=multi-user.target
EOF
sudo systemctl daemon-reload
sudo systemctl enable --now rust-server.service
journalctl -u rust-server -f

Nach diesem Setup läuft ein einsatzbereites System mit automatischem Neustart. Oxide oder Carbon (Schritt 11), das Wipe-Skript (Schritt 12) und die Backup-Automatisierung (Schritt 13) lassen sich anschließend unabhängig ergänzen, sobald Grundbetrieb und Erreichbarkeit bestätigt sind.

Häufig gestellte Fragen

Wie viel RAM braucht ein Rust-Server wirklich?

Facepunchs eigene Dokumentation nennt 12 GB freien Arbeitsspeicher als Richtwert, während viele Hosting-Anleitungen kleine Aufbauten bereits mit 4–8 GB betreiben. In der Praxis hängt der Bedarf stark von Weltgröße und Spielerzahl ab – für einen Standard-Aufbau mit 4.500er-Worldsize sind 16 GB eine sichere Empfehlung.

Ist Rust-Server-Hosting kostenlos möglich?

Die Software selbst ist über SteamCMD kostenlos. Kosten entstehen ausschließlich für die Hardware – entweder als eigener Root-Server/VPS oder als Mietpaket bei einem Hosting-Anbieter, wo Angebote laut ZAP-Hosting bei rund 8,64 € pro Monat beginnen.

Wie oft wird gewiped?

Facepunch erzwingt auf offiziellen Servern einen Wipe am ersten Donnerstag jedes Monats um 19:00 UTC, inklusive Blueprint-Reset. Die meisten Community-Betreiber übernehmen diesen Rhythmus, zusätzliche Zwischen-Wipes sind eine freie Entscheidung.

Brauche ich einen Steam-Account für die Installation?

Nein. Die Installation über SteamCMD erfolgt mit einem anonymen Login, da Facepunch die Dateien öffentlich bereitstellt. Ein Steam-Account wird nur zum Spielen als Client benötigt.

Läuft das Ganze auch unter Windows?

Ja, RustDedicated ist sowohl für Linux als auch für Windows verfügbar. Diese Anleitung konzentriert sich auf Linux, da die meisten VPS- und Root-Server-Angebote in Deutschland auf Distributionen wie Ubuntu oder Debian basieren und günstiger sind als Windows-Server-Lizenzen.

Was ist der Unterschied zwischen Oxide und Carbon?

Oxide (uMod) ist das etablierte Framework mit der größten Plugin-Bibliothek, befindet sich aber im Wartungsmodus. Carbon ist die aktiv weiterentwickelte Alternative mit 2026 nahezu vollständiger Plugin-Kompatibilität zu Oxide und laut Benchmarks spürbar schnelleren Boot-Zeiten. Beide lassen sich nicht gleichzeitig auf demselben System betreiben.

Wie viele Spieler verträgt ein Rust-Server?

server.maxplayers lässt sich frei setzen, in der Praxis limitiert die Hardware die realistische Obergrenze. Mit der empfohlenen Konfiguration (6–8 Kerne, 16 GB RAM) sind 100 bis 150 gleichzeitige Spieler stabil realisierbar, für 200+ Spieler braucht es entsprechend leistungsfähigere Hardware.

Ist Easy Anti-Cheat Pflicht?

Praktisch ja: server.secure 1 aktiviert EAC und sollte auf öffentlich zugänglichen Installationen immer eingeschaltet bleiben. Ohne aktives EAC verweigern viele Clients die Verbindung oder der Eintrag gilt als unsicher, was ihn für die meiste Spielerbasis unattraktiv macht.

Wie schütze ich meinen Server vor DDoS-Angriffen?

Ein vollständiger Schutz erfordert meist einen spezialisierten Anti-DDoS-Tarif beim Hosting-Anbieter oder einen vorgeschalteten Reverse-Proxy-Dienst, da sich volumetrische Angriffe auf Netzwerkebene kaum selbst abwehren lassen. SSH-Härtung, ein isolierter RCON-Zugriff und zeitnahe Updates aus dem Sicherheitskapitel dieser Anleitung reduzieren zumindest die Angriffsfläche für gezielte Übernahmeversuche erheblich.

Kann ich mehrere Server auf derselben Maschine betreiben?

Ja, solange jede Instanz eine eigene server.identity, eigene Ports (Spiel-, Query- und RCON-Port) und ausreichend zusätzliche Hardware-Ressourcen bekommt. Am saubersten gelingt das mit einer eigenen Kopie des Installationsverzeichnisses und einer eigenen systemd-Unit-Datei pro Instanz, damit sich die Prozesse nicht gegenseitig überschreiben.

Was passiert mit meinen Plugins bei einem Rust-Update?

Größere Rust-Updates ändern gelegentlich interne Schnittstellen, auf die Oxide- und Carbon-Plugins zugreifen. In der Regel folgt das jeweilige Framework mit einem Update innerhalb weniger Stunden bis Tage, einzelne Plugins können trotzdem vorübergehend Fehler werfen, bis auch deren Autoren nachziehen. Ein Backup vor jedem großen Update (Schritt 13) und ein Testsystem für die ersten Stunden nach dem Patch vermeiden böse Überraschungen auf dem Live-System.