Ein öffentlicher Minecraft-Server scheitert selten, weil der Betreiber die „falsche Spielerzahl“ gewählt hat. Er scheitert, weil 40 Spieler bei einem Event beitreten, alle neues Gelände erkunden, drei Farmen laufen und der Haupt-Thread des Servers einen Tick nicht rechtzeitig abschließen kann. Dieser Kapazitäts-Guide für öffentliche Server hilft dir, für diese echten Momente zu dimensionieren, nicht für die Zahlen bei leerer Lobby, die einen Hosting-Tarif beeindruckend wirken lassen können.
Bei öffentlichen Projekten ist Kapazität nicht nur RAM. Sie ist die Balance zwischen hoher Single-Core-Leistung der CPU, verfügbarem Speicher, schnellem Speicherplatz, deinem Software-Stack und genug Raum für plötzliche Spielerspitzen. Triffst du diese Balance, erinnern sich die Spieler an flüssige Kämpfe, schnelles Chunk-Laden und einen Server, der online bleibt, wenn die Discord-Ankündigung rausgeht.
Was die Kapazität öffentlicher Server tatsächlich begrenzt
Die Kapazität von Minecraft hat eine Hauptregel: Der Server fühlt sich nur gesund an, wenn er 20 TPS halten kann. Bei 20 TPS verarbeitet das Spiel alle 50 Millisekunden einen Tick. Steigt die Tick-Zeit über diese Grenze, reagieren Mobs spät, Redstone-Timing bricht zusammen, Blöcke werden langsam gesetzt, und die Spieler nennen es Lag.
Bei den meisten Paper-, Purpur-, Forge- und Fabric-Servern ist die CPU die erste Einschränkung. Minecraft nutzt für manche Arbeit zwar mehr als einen Thread, aber die primäre Tick-Schleife stützt sich weiterhin stark auf einen schnellen CPU-Kern. Mehr vCPUs sind nützlich für Netzwerk, Weltgenerierung, Plugins, Datenbankaufgaben und Hintergrundarbeit. Sie ersetzen keine starke Single-Core-Leistung.
Der RAM ist die zweite Einschränkung, besonders auf gemoddeten Servern. Zu wenig Speicher verursacht Pausen der Garbage Collection, Abstürze und Ruckler beim Chunk-Laden. Zu viel Speicher kann ebenfalls kontraproduktiv sein, wenn er achtlos zugeteilt wird. Java braucht vernünftige JVM-Flags und genug freien Platz für Betriebssystem und Panel-Prozesse. Einer kleinen Vanilla-Welt 20 GB zu geben, lässt sie nicht auf magische Weise 100 Spieler verkraften.
Der Speicher zählt, wann immer deine Spieler Gelände generieren, oft teleportieren oder eine große Welt mit häufigen Backups betreiben. NVMe-Speicher reduziert die Zeit, die mit dem Lesen und Schreiben von Chunks, Spielerdaten, Logs und Weltdateien verbracht wird. Er löst kein CPU-gebundenes TPS-Problem, aber langsame Festplattenleistung kann normale Erkundung in eine schmerzhafte Erfahrung verwandeln. Wie die drei Teile zusammenpassen, behandelt unser Hardware-Guide für Server.
Fang mit deinem Servertyp an
Eine Spieler-Slot-Zahl allein ist keine Kapazitätsplanung. Ein SMP mit 30 Spielern, enger Weltgrenze und einfachen Komfort-Plugins läuft womöglich wunderbar mit Ressourcen, mit denen 10 Spieler auf einem stark gemoddeten Forge-Modpack kämpfen würden.
Nutz den Servertyp als Ausgangspunkt und füg dann Reserve dafür hinzu, wie deine Community tatsächlich spielt.
| Server-Setup | Realistischer Ausgangspunkt | Was den Bedarf verändert |
|---|---|---|
| Vanilla- oder leichter Paper-SMP | 4–6 GB RAM | View-distance, Farmen, Erkundung, Gleichzeitigkeit zur Spitzenzeit |
| Plugin-lastiger Paper- oder Purpur-Server | 6–10 GB RAM | Wirtschaft, Claims, Minispiele, NPCs, eigene Mobs, Datenbanken |
| Kleines Fabric-Modpack | 6–10 GB RAM | Zahl der Mods, Geländegenerierung, clientseitig benötigte Inhalte |
| Gemoddete Forge-Community | 8–16 GB RAM | Große Content-Mods, Dimensionen, Automatisierung, Entities |
| Netzwerk mit Proxy und Spielmodi | Getrennte Ressourcen pro Backend | Proxy-Verkehr, Lobby-Design, Spielerverteilung, serverübergreifende Daten |
Das sind Ausgangsbereiche, keine Versprechen. Ein sauberer Paper-Server mit 6 GB und gut gewählten Plugins kann einen 12-GB-Server übertreffen, der mit ineffizienten Skripten, unoptimierten Farmen und unbegrenzter view-distance vollgepackt ist. Für eine schnelle Schätzung für dein eigenes Setup probier den RAM-Rechner.
Öffentliche Vanilla- und Paper-Server
Für einen neuen öffentlichen SMP reichen meist 4–6 GB RAM für einen kontrollierten Start mit vernünftigem Spielerlimit, besonders mit Paper oder Purpur. Die eigentliche Priorität ist schnelle CPU-Leistung von Ryzen oder EPYC und eine Server-Konfiguration, die verhindert, dass Spieler am ersten Tag Tausende Chunks in jede Richtung generieren.
Nutzt dein Server Claims, Ränge, Kosmetik, Discord-Integration, Crates, Jobs, Auktionen, eigene Items und aktive Moderations-Tools, plane eher mit 6–10 GB. Jedes Plugin wirkt für sich klein, aber öffentliche Server sammeln schnell Features an. Wichtiger noch: Plugins können jedem Tick Arbeit hinzufügen, was die TPS beeinflusst, lange bevor der Speicher voll ist — unsere Analyse, wie viel RAM ein Paper-Server braucht, geht tiefer.
Gemoddete Forge- und Fabric-Server
Die Kapazität gemoddeter Server verzeiht weniger. Mods bringen Blöcke, Entities, Rezepte, Dimensionen, Regeln zur Weltgenerierung, Automatisierungssysteme und Hintergrundberechnungen mit. Ein Modpack mit 150 leichten Mods ist nicht automatisch schwerer zu hosten als eines mit 60 großen Tech- und Magie-Mods. Der Inhalt zählt mehr als die reine Mod-Anzahl.
Starte ein öffentliches Forge-Projekt mit genug Speicher, um das Modpack bequem zu laden, und lass dann Raum für aktive Spieler und normale Garbage Collection. Für viele Modpacks sind 8 GB eine vernünftige Untergrenze. Größere Modpacks oder Communities mit automatisierungslastigen Basen brauchen oft 12–16 GB oder mehr — siehe wie viel RAM ein gemoddeter Server braucht.
Dimensionier einen gemoddeten Server nicht nach dem RAM, den dein eigener PC verbraucht. Dein lokaler Client lädt Texturen, Shader und Rendering-Assets, die der Server nicht braucht. Teste den dedizierten Server selbst mit echten Spielern, generiertem Gelände und typischen Basen aus dem späten Spiel.
Plane für Spitzen, nicht für durchschnittliche Spieler
Hat dein Server im Schnitt 12 Spieler, erreicht bei Wochenend-Events aber 35, sollte die Kapazität um 35 herum gebaut sein. Öffentliche Communities sind sprunghaft. Ein TikTok-Clip, ein Creator-Stream, ein Reset-Tag, ein Update-Start oder ein PvP-Turnier kann in einer Stunde mehr Last erzeugen als ein ruhiger Wochentag an einem ganzen Tag.
Eine gute Regel ist, während deiner normalen Spitze 25–35 % Reserve zu behalten. Beginnt der Server zu kämpfen, sobald er sein erwartetes Maximum erreicht, bleibt kein Raum für Erkundung, eine versehentliche Mob-Farm oder eine Plugin-Aufgabe, die zur falschen Zeit läuft.
Achte auf diese Signale, statt dich auf Slot-Limits zu verlassen:
- TPS bei aktivem Spiel dauerhaft unter 19,5
- Tick-Zeit, die sich 50 ms nähert oder sie überschreitet
- RAM nahe am Limit oder häufige Out-of-Memory-Fehler
- Lange Pausen der Garbage Collection
- Spitzen bei der Chunk-Generierung, wenn Spieler erkunden
- CPU-Sättigung im Haupt-Thread des Servers
Nutz einen Profiler, wenn die Leistung sinkt. Tools wie spark zeigen, ob das Problem von einem Plugin, Entities, Redstone, Chunk-Generierung, einer bestimmten Welt oder einer gemoddeten Maschine kommt. Raten führt zu unnötigen Upgrades. Messen sagt dir, ob du optimieren, ein Feature begrenzen, Gelände vorgenerieren oder den Tarif skalieren solltest — die vollständige Diagnose steht in unserem Guide zum Beheben niedriger TPS.
Nimm deine echte Wochenendspitze und füg ein Drittel hinzu: Sind 35 Spieler ein normaler voller Abend, sollte der Server mit rund 45 online 20 TPS halten. Prüf es dann während eines echten Events mit laufendem spark, nicht in einer leeren Lobby. Die Zahlen von diesem einen Abend sind mehr wert als jedes Datenblatt.
Einstellungen, die deine Kapazität schnell verändern
View-distance und simulation-distance sind zwei der größten verfügbaren Kapazitätshebel. Die view-distance steuert, wie viel Gelände Spieler sehen können. Die simulation-distance steuert, wie weit Entities, Pflanzen, Redstone und andere tickende Systeme aktiv bleiben. Die simulation-distance vernünftig zu halten, schützt die TPS meist besser, als einfach den RAM zu erhöhen — empfohlene Werte stehen in unserem Guide zu Paper-Einstellungen.
Die Vorgenerierung der Welt ist ein weiterer praktischer Gewinn für öffentliche Starts. Neue Chunks zu generieren, ist teuer, besonders mit eigenem Gelände oder gemoddeter Weltgenerierung. Generier den Bereich vor, den Spieler wahrscheinlich zuerst erkunden, und erweitere ihn, wenn die Community wächst. So wird es viel unwahrscheinlicher, dass die Erkundung am Starttag CPU und Festplatte gleichzeitig malträtiert — siehe Chunk-Ladelast reduzieren.
Auch die Kontrolle von Entities zählt. Item-Haufen, unbeaufsichtigte Farmen, Dorfbewohner-Hallen, Trichterketten, Rüstungsständer und Mobs in geladenen Chunks fügen alle wiederkehrende Arbeit hinzu. Das Ziel ist nicht, deinen Server einschränkend wirken zu lassen. Sondern klare Grenzen zu setzen, bevor die Maschine eines Spielers das Erlebnis aller anderen verschlechtert.
Prüf bei Plugin-Servern jede Ergänzung. Installier nur, was das Spielerlebnis oder den Betrieb unterstützt. Ein „kleines“ Plugin, das die ganze Welt scannt, eine synchrone Datenbankabfrage ausführt oder in jedem Tick jeden Spieler prüft, kann mehr kosten als mehrere gut gebaute Plugins zusammen.
Wann ein Server nicht mehr das richtige Design ist
Irgendwann ist das Hochskalieren einer einzelnen Instanz nicht mehr der beste Schritt. Betreibst du eine Lobby, eine Survival-Welt, SkyBlock, Minispiele, Events und Kreativ-Grundstücke, gibt die Aufteilung auf getrennte Backend-Server jedem Modus sein eigenes Leistungsbudget. Ein Proxy wie BungeeCord oder Velocity kann Spieler zwischen ihnen leiten, ohne dass sich das Netzwerk zersplittert anfühlt.
Dieser Ansatz senkt auch das Risiko. Ein volles Event-Server sollte deinen Haupt-SMP nicht unspielbar machen. Ein Modpack-Update sollte nicht verlangen, eine unabhängige Lobby herunterzufahren. Der Kompromiss ist mehr Einrichtung und mehr Abstimmung bei Rechten, Spielerdaten, Chat und gemeinsamen Wirtschaftssystemen.
Für einen einzelnen öffentlichen SMP halte die Architektur einfach, bis die Daten etwas anderes sagen. Für ein wachsendes Netzwerk ist die Trennung meist sauberer, als zu versuchen, eine riesige Welt alles erledigen zu lassen.
Bau einen Kapazitätsplan, den du hochstufen kannst
Starte mit einem Spielerlimit, das dein Server wirklich verkraften kann, nicht mit der Zahl, die du zu erreichen hoffst. Richte Warnungen ein, prüf die TPS nach Events und halte Backups automatisch, bevor Wachstum jede Änderung riskant wirken lässt. Schneller NVMe-Speicher, DDoS-Schutz und getestete Backups sind keine auffälligen Features, schützen aber die Welt, die deine Community über Monate aufgebaut hat.
Elysium ist für genau diese Art praktischen Skalierens gebaut: mit der richtigen Minecraft-Konfiguration starten, beobachten, wie Spieler sie nutzen, und Ressourcen hinzufügen, bevor Lag zum Ruf deines Servers wird — mehr dazu in Hosting für öffentliche Server, das mitwächst. Deine Community braucht am ersten Tag keine überdimensionierte Maschine. Sie braucht einen Server, der schnell bleibt, wenn der Spaß endlich voll wird.
Elysium-Tarife laufen auf hochgetakteten Ryzen-CPUs mit NVMe Gen4, DDoS-Schutz und automatischen Backups, und du kannst in deinem Dashboard auf einen größeren Tarif wechseln. Vergleiche Tarife auf der Bestellseite oder lass uns einen öffentlichen Server umziehen, der seinem aktuellen Hoster entwachsen ist.