Rust Server: Anforderungen und DimensionierungKartengröße, Plugins und Spielerzahl richtig einschätzen

Veröffentlicht am 9. August 2026 · zuletzt aktualisiert am 2. September 2026

Die Kartengröße ist der Haupttreiber

Der Wert server.worldsize bestimmt, wie groß die prozedurale Karte wird - und der Rechenaufwand wächst nicht linear, sondern mit der Fläche. Eine Verdopplung der Kantenlänge vervierfacht grob die Welt.

Wichtig: Eine große Karte mit wenigen Spielern ist teurer als eine kleine mit vielen. Wer die Ausstattung senken will, senkt zuerst die Kartengröße - siehe worldsize & seed ändern.

Entities: was über die Wochen dazukommt

Ein frisch gewipeter Server ist leicht. Der Bedarf wächst im Laufe des Wipe-Zyklus, weil Spieler bauen:

• Jedes Bauteil, jede Kiste und jede Falle ist eine Entity, die dauerhaft berechnet wird.
• Große Clan-Basen mit hunderten Bauteilen fallen deutlich ins Gewicht.
• Elektrik und Industrie-Anlagen kosten zusätzlich Rechenzeit in jedem Tick.

Praktische Folge: Ein Server, der direkt nach dem Force Wipe flüssig läuft, kann drei Wochen später spürbar langsamer sein. Dimensioniere für das Ende des Zyklus, nicht für den Anfang.

Warum die Spielerzahl der schlechteste Maßstab ist

Fast jede Anbieterseite sortiert Gameserver nach Spielerzahl. Bei Rust führt das in die Irre, denn der Server simuliert die Welt unabhängig davon, wie viele Leute gerade verbunden sind. Gelände, Monumente, Tiere und sämtliche gespeicherten Objekte werden auch dann berechnet, wenn nachts niemand online ist.

Ein zusätzlicher Spieler kostet vor allem Netzwerklast und die Berechnung dessen, was er in seiner unmittelbaren Umgebung tut. Gegenüber der Grundlast der Welt fällt das wenig ins Gewicht. Der Vergleich, den man sich merken sollte: Zehn Spieler auf einer 4500er-Karte belasten den Server in der Regel stärker als fünfzig auf einer 3000er.

Bei uns ist die Spielerzahl schon deshalb kein Preisfaktor: Die Slots sind unbegrenzt, bezahlt werden RAM, Speicher und Rechenleistung. Die Obergrenze setzt du selbst über server.maxplayers in der server.cfg - aus Spielgründen, nicht weil eine Lizenz sie erzwingt. Warum die Slot-Zahl als Maß insgesamt ausgedient hat, steht in Gameserver-Slots erklärt.

Eine Obergrenze ist trotzdem sinnvoll: Sie verhindert, dass die Karte am vollen Wipe-Day so zuläuft, dass niemand mehr Bauplatz findet - und schützt damit genau das Spielgefühl, für das du die Kartengröße gewählt hast. Als Orientierung dient die Slot-Empfehlung je Tarif auf der Rust-Produktseite; sie ist eine Empfehlung, keine technische Sperre.

Plugins und Framework

Ein modded Server braucht mehr als Vanilla. Der Aufschlag hängt weniger an der Zahl der Plugins als daran, was sie tun:

• Leichte Plugins - Chat, Ränge, Willkommensnachrichten. Kaum spürbar.
• Mittlere Last - Shops, Kits, Teleport, Gather-Rate-Plugins.
• Schwergewichte - Events, NPCs, Zonen und alles, was dauerhaft die Welt abtastet.

Ein einzelnes schlecht geschriebenes Plugin kann mehr kosten als zwanzig gute. Welches, zeigt die Analyse in Performance & FPS optimieren. Die Wahl des Frameworks selbst - Oxide oder Carbon - macht beim Bedarf keinen dramatischen Unterschied.

Woran du einen zu kleinen Server erkennst

• Server-FPS unter 30 im laufenden Betrieb - der wichtigste Indikator bei Rust.
• Spürbare Verzögerung beim Bauen und beim Öffnen von Kisten.
• Sehr lange Startzeit beim Laden der Karte.
• Zunehmende Trägheit über den Wipe-Zyklus hinweg.
• Abbrüche mit Speichermeldungen - siehe Server startet nicht.

Tritt das erst gegen Ende des Zyklus auf, ist die Karte zu groß für die Ausstattung. Tritt es schon direkt nach dem Wipe auf, ist die Ausstattung grundsätzlich zu knapp.

Messen statt schätzen: drei Werte über den Zyklus

Statt den Bedarf vorab zu rechnen, liest du ihn am laufenden Server ab. Drei Werte genügen - entscheidend ist, sie einmal kurz nach dem Wipe und einmal gegen Ende des Zyklus zu erfassen und zu vergleichen:

• Server-FPS über server.fps in der Konsole, gemessen zur Stoßzeit. Der Verlauf über die Wochen sagt mehr aus als jeder Einzelwert.
• RAM-Auslastung im Webinterface, ebenfalls zur Stoßzeit und nicht nachts bei drei Spielern.
• Größe des Identity-Ordners per WebFTP oder SFTP. Sie wächst mit der Zahl der gespeicherten Objekte und ist damit das direkteste Maß für die Entity-Last, das du ohne Zusatzwerkzeug bekommst.

Wächst der Ordner deutlich, während die Server-FPS im selben Zeitraum fallen, hast du die Ursache belegt, statt sie zu vermuten. In dieselbe Richtung deutet ein Speichervorgang, der spürbar länger wird - kurze Hänger im Abstand von server.saveinterval sind ein verlässliches Frühwarnzeichen.

Die Grenze dieser Methode: Sie zeigt dir, dass die Last steigt, nicht welches Plugin daran beteiligt ist. Dafür ist die schrittweise Analyse in Performance & FPS optimieren der richtige Weg - erst danach lohnt die Frage nach einem größeren Paket.

Die richtige Reihenfolge beim Planen

1. Kartengröße festlegen - sie bestimmt die Grundlast.
2. Modded oder Vanilla entscheiden - Plugins kommen obendrauf.
3. Wipe-Zyklus wählen - kurze Zyklen halten die Entity-Zahl niedrig, lange lassen sie wachsen.
4. Erst dann den Tarif wählen - die Staffeln stehen auf der Rust-Produktseite.

Wer unsicher ist, startet lieber mit einer kleineren Karte und wächst. Eine 4500er-Karte auf zu knapper Ausstattung frustriert alle - eine gut laufende 3000er-Karte nicht. Allgemeine Richtwerte quer über alle Spiele stehen in Wie viel RAM brauche ich?.

Zwei Punkte nehmen der Entscheidung den Druck. Erstens ist ein Upgrade auf ein größeres Paket jederzeit möglich, ohne dass Welt, Plugins und Konfiguration verloren gehen - du musst also nicht heute festlegen, wie groß dein Server in einem halben Jahr ist. Zweitens lässt sich die Kartengröße beim nächsten Wipe ohnehin neu wählen: Wer merkt, dass 4500 zu groß war, startet den kommenden Zyklus mit 3500 und hat das Problem an der Wurzel gelöst.

Nicht Teil des Tarifs sind automatische Sicherungen - Backups laufen bei uns durchgehend als Self-Service über den WebFTP-Dateimanager oder per SFTP. Plane die paar Minuten vor jedem größeren Eingriff mit ein, etwa vor einem Framework-Update oder einem Kartenwechsel, siehe Backups erstellen.

Häufige Fragen