Folia für Minecraft: Wie regionsbasiertes Multithreading die Server-Performance neu definiert
Lange Zeit galt eine unangenehme Wahrheit für jeden ambitionierten Minecraft-Serverbetreiber: Egal wie viele CPU-Kerne im Server stecken, der eigentliche Spiel-Tick läuft auf einem einzigen Thread. Genau hier setzt Folia für Minecraft an. Folia ist ein offizieller Fork von Paper, der die Spielwelt in unabhängige Regionen aufteilt und diese parallel über mehrere CPU-Kerne hinweg berechnet. Für große, weit verteilte Spielergruppen verspricht das eine deutlich bessere Skalierung als klassische Server-Software. In diesem ausführlichen Artikel erklären wir, was Folia ist, warum es entwickelt wurde, wie es technisch funktioniert und für welche Server es sich wirklich lohnt – sachlich, fundiert und ohne Marketing-Versprechen. Am Ende findest du eine vollständige Quellenliste.
Was ist Folia?
Folia ist eine Server-Software für Minecraft und ein Fork von Paper, der dem dedizierten Server sogenanntes *regionised multithreading* (regionsbasiertes Multithreading) hinzufügt. In den Worten des PaperMC-Projekts selbst handelt es sich um „a fork of Paper which adds regionised multithreading to the dedicated server".
Um das einzuordnen, hilft ein kurzer Blick auf die Hierarchie der gängigen Server-Software:
Der entscheidende Punkt: Folia ist kein Drop-in-Ersatz für Paper. Es ist ein spezialisiertes Werkzeug für einen bestimmten Anwendungsfall – nämlich Server mit sehr hohen Spielerzahlen, die über die Welt verteilt sind. Folia setzt voraus, dass Plugins ausdrücklich für Folia angepasst wurden, und richtet sich primär an erfahrene Betreiber und Hosting-Anbieter mit leistungsstarker Hardware.
Begriff erklärt – Fork: Ein „Fork" ist eine abgespaltene Weiterentwicklung eines Softwareprojekts. Folia übernimmt den kompletten Code von Paper als Grundlage und erweitert ihn um eigene Funktionen.
Warum wurde Folia entwickelt?
Minecraft-Server haben ein grundlegendes architektonisches Problem, das seit den frühen Tagen des Spiels existiert: Die zentrale Spielschleife – der sogenannte Tick – läuft auf einem einzigen Hauptthread („main thread"). Pro Sekunde sollen 20 Ticks ausgeführt werden (20 TPS), in denen die gesamte Spiellogik berechnet wird: Bewegung von Entitäten, Redstone, Mob-KI, Block-Updates, Pflanzenwachstum, Spieleraktionen und vieles mehr.
Solange alles in 50 Millisekunden pro Tick passt, läuft der Server flüssig. Sobald die Berechnungen länger dauern, sinkt die TPS-Rate – das Spiel beginnt zu „laggen". Das eigentliche Problem dabei: Moderne CPUs werden nicht durch höhere Taktraten, sondern durch mehr Kerne schneller. Ein Server mit 32 Kernen nützt einem klassischen Minecraft-Server wenig, weil der Haupt-Tick nur einen einzigen davon auslasten kann. Die übrigen Kerne übernehmen nur Nebenaufgaben wie Netzwerk-I/O oder Chunk-Generierung.
Folia wurde geschaffen, um genau diese Wand zu durchbrechen. Die Idee: Wenn Spieler sich ohnehin über die Welt verteilen, müssen die voneinander entfernten Bereiche nicht zwingend auf demselben Thread berechnet werden. Stattdessen lassen sich unabhängige Weltregionen parallel auf mehreren Kernen ticken. Damit wird erstmals die volle Rechenleistung moderner Mehrkern-Prozessoren für die eigentliche Spiellogik nutzbar.
Die größten Performance-Probleme klassischer Minecraft-Server
Bevor wir tiefer in die Technik von Folia einsteigen, lohnt es sich, die typischen Engpässe klassischer Server zu verstehen. Sie erklären, warum Multithreading überhaupt so attraktiv ist.
Paper hat über Jahre viele dieser Probleme entschärft – durch asynchrones Chunk-Laden, optimierte Entity-Verarbeitung und feingranulare Konfiguration. Doch die fundamentale Single-Thread-Natur des Haupt-Ticks blieb. Genau hier setzt Folia mit einem radikal anderen Ansatz an.
Wie funktioniert Folia technisch?
Regionised Multithreading
Das Herzstück von Folia ist das regionsbasierte Multithreading. Anstatt die gesamte Welt auf einem Thread zu ticken, gruppiert Folia nahe beieinander liegende, geladene Chunks zu unabhängigen Regionen (Regions). Laut PaperMC-Dokumentation gilt: „Each independent region has its own tick loop, which is ticked at the regular Minecraft tickrate (20TPS). The tick loops are executed on a thread pool in parallel."
Jede Region hat also ihre eigene Tick-Schleife, die mit den normalen 20 TPS läuft, und diese Schleifen werden auf einem Thread-Pool parallel ausgeführt. Ganz wichtig ist die Formulierung des Projekts: Die Regionen ticken „in parallel, and not concurrently" – also echt parallel auf verschiedenen Kernen, aber ohne dass sie sich Daten teilen.
Begriff erklärt – Chunk: Ein Chunk ist ein 16×16-Block-Abschnitt der Welt. Minecraft lädt und verarbeitet die Welt in solchen Einheiten.
Wie entsteht eine Region? Vereinfacht gesagt: Folia fasst benachbarte Chunks zusammen, solange sie nah genug beieinander liegen. Technisch arbeitet der sogenannte Regionizer nicht mit einzelnen Chunks, sondern mit „region sections" – Gruppen von NxN Chunks auf einem Raster (wobei N eine Zweierpotenz ist). Laut Dokumentation ist „a region simply a set of owned chunk positions and implementation defined unique data object tied to that region". Bewegen sich Spieler aufeinander zu, verschmelzen (merge) Regionen; entfernen sie sich, können Regionen wieder aufgeteilt (split) werden.
Unterschied zu Paper
Der Kernunterschied lässt sich in einem Satz zusammenfassen: Paper tickt eine Welt auf einem Hauptthread, Folia tickt viele unabhängige Regionen parallel.
Paper ist hochgradig optimiert, bleibt aber dem klassischen Modell treu: Es gibt einen Haupt-Tick, und Plugins können sich darauf verlassen, dass ihr Code auf diesem einen Thread läuft. Das macht Paper extrem kompatibel – nahezu jedes Bukkit/Spigot-Plugin funktioniert.
Folia bricht mit dieser Annahme. Es gibt keinen einzelnen Hauptthread mehr, auf den sich Plugins verlassen können. Stattdessen „besitzt" jede Region ihre eigenen Daten (Entitäten, Chunks, Points of Interest), und nur der Thread, der diese Region gerade tickt, darf auf diese Daten zugreifen. Diese Datenisolation ist der Grund, warum die parallele Verarbeitung überhaupt sicher ist – und gleichzeitig der Grund, warum bestehende Plugins angepasst werden müssen.
Threading-Konzept
Damit die parallele Verarbeitung nicht zu Datenkorruption führt, setzt Folia auf strikte Regeln und neue Scheduler-APIs.
Datenbesitz als Grundprinzip: Eine Region besitzt die Daten in ihren Chunks exklusiv. Wie das Projekt betont, kommt „the only guarantee of thread-safety [...] from the fact that a single region owns data in certain chunks" – und dieser Datenbesitz bezieht sich auf Entity-, Chunk- und POI-Daten, ausdrücklich nicht auf Plugin-eigene Daten. Plugins müssen ihre eigene Thread-Sicherheit also selbst gewährleisten.
Vier Invarianten sichern die Parallelität: Die Dokumentation beschreibt mehrere unverrückbare Regeln, darunter: Jeder Chunk gehört zu genau einer Region; Regionen halten Pufferzonen zu Nachbarn ein; und besonders wichtig – „a ticking region cannot expand the chunk positions it owns as it ticks". Eine tickende Region kann ihren Besitz also nicht mitten im Tick ausweiten. Das verhindert, dass zwei parallel laufende Regionen um dieselben Chunks „kämpfen".
Neue Scheduler statt klassischem BukkitScheduler: Da es keinen Hauptthread mehr gibt, ersetzt Folia den klassischen BukkitScheduler durch drei neue APIs:
Begriff erklärt – Scheduler: Ein Scheduler plant die Ausführung von Code zu einem bestimmten Zeitpunkt (z. B. „im nächsten Tick"). In Folia muss dabei zusätzlich die Region berücksichtigt werden, die für den jeweiligen Ort oder die jeweilige Entität zuständig ist.
Skalierung auf moderne CPUs
Hier zahlt sich Folias Architektur aus. Weil die Regionen parallel auf einem konfigurierbaren Thread-Pool laufen, kann Folia – im Gegensatz zu klassischen Servern – tatsächlich von vielen CPU-Kernen profitieren. Wie das Projekt formuliert: Für Server mit vielen verteilten Spielern „Folia will create many spread out regions and tick them all in parallel on a configurable sized threadpool, which should scale well".
Entsprechend deutlich sind die Hardware-Empfehlungen. Das Projekt nennt als Richtwert „ideally, at least 16 cores (not threads)" – also mindestens 16 echte CPU-Kerne, nicht nur logische Threads. Für die Thread-Verteilung gibt die Dokumentation grobe Anhaltspunkte pro 200–300 Spieler: rund 4 Threads für Netty-I/O (Netzwerk), etwa 3 für Chunk-System-I/O, etwa 2 für Chunk-Worker bei vorgenerierten Welten – und die restlichen Kerne bis zu einer Auslastung von rund 80 % werden den Tick-Threads zugewiesen.
Wichtig zur Einordnung: Folia parallelisiert nicht eine einzelne, dicht gedrängte Region über viele Kerne. Eine Region läuft weiterhin auf einem Thread. Der Gewinn entsteht durch viele voneinander getrennte Regionen. Sind alle Spieler an einem Ort, gibt es im Wesentlichen eine große Region – und Folia verhält sich dort kaum anders als ein klassischer Server.
Die wichtigsten Vorteile von Folia
Bessere Nutzung mehrerer CPU-Kerne
Der zentrale Vorteil: Folia macht die in modernen Servern vorhandene Mehrkern-Leistung für die eigentliche Spiellogik nutzbar. Statt 31 von 32 Kernen weitgehend brachliegen zu lassen, verteilt Folia die Last verteilter Regionen über den Thread-Pool. Für die richtige Workload bedeutet das eine grundlegend andere Skalierungskurve als bei Paper.
Höhere Spielerzahlen
Weil die Last verteilter Spieler auf mehrere Kerne aufgeteilt wird, kann ein einzelner Folia-Server theoretisch deutlich mehr Spieler tragen als ein vergleichbarer Paper-Server – vorausgesetzt, die Spieler sind über die Welt verteilt. Das PaperMC-Projekt nennt als ideale Kandidaten ausdrücklich Spielmodi, „that naturally spread players out, like skyblock or SMP". Server, die früher horizontal über mehrere Instanzen und Proxies skaliert werden mussten, lassen sich so unter Umständen auf einer einzigen Instanz betreiben.
Stabilere TPS
Ein langsamer Vorgang in einer Region (etwa eine große Redstone-Anlage in einem Spielerbereich) blockiert nicht automatisch die gesamte Welt. Andere Regionen ticken unabhängig weiter. Dadurch können lokale Lastspitzen besser isoliert werden, statt den ganzen Server in die Knie zu zwingen – ein wesentlicher Unterschied zum Single-Thread-Modell.
Zukunftssichere Architektur
Der Trend bei CPUs geht seit Jahren klar zu mehr Kernen statt höherer Taktraten. Eine Server-Architektur, die echte Parallelität unterstützt, ist deshalb langfristig besser aufgestellt. Viele Betreiber betrachten regionsbasiertes Multithreading deshalb als den architektonisch konsequenten nächsten Schritt – also als „die Zukunft" performanter Minecraft-Server, gerade für große Netzwerke.
Verbesserte Skalierbarkeit
Folia skaliert nicht nur mit der Spielerzahl, sondern auch mit der Hardware. Wer mehr Leistung braucht, kann (innerhalb sinnvoller Grenzen) mehr Kerne bereitstellen und den Thread-Pool entsprechend dimensionieren. Dieses „vertikale" Skalieren auf einer einzigen, leistungsstarken Maschine kann die Architektur eines Netzwerks erheblich vereinfachen.
Wichtige Einordnung: Diese Vorteile gelten für den passenden Anwendungsfall. Für die Mehrheit der Server – kleine Communitys, Lobbys, Minispiele mit gebündelten Spielern – bringt Folia keinen Vorteil und kostet wegen der Plugin-Problematik eher Aufwand. Folia ist ein Spezialwerkzeug, kein universelles Upgrade.
Folia vs Paper
Die folgende Tabelle vergleicht beide Server-Softwarelösungen objektiv. Sie soll keine Empfehlung „für alle" aussprechen, sondern die Unterschiede entlang der relevanten Dimensionen aufzeigen.
| Kriterium | Paper | Folia |
|---|---|---|
| Performance | Sehr hoch und ausgereift, aber begrenzt durch den Single-Thread-Haupt-Tick. Ideal für die allermeisten Server. | Potenziell deutlich höher bei verteilten Spielern, weil Regionen parallel ticken. Kein Vorteil bei gebündelten Spielern. |
| Kompatibilität | Praktisch zu allen Bukkit-/Spigot-/Paper-Plugins kompatibel. Drop-in-Ersatz für Spigot. | Kein Drop-in-Ersatz. Lädt nur explizit als Folia-kompatibel markierte Plugins. |
| Plugin-Unterstützung | Riesiges Ökosystem, nahezu jedes öffentliche Plugin läuft. | Stark eingeschränkt. „Basically zero" Paper-Plugins laufen ohne Anpassung; Autoren müssen ihren Code migrieren. |
| Multithreading | Nebenaufgaben (Chunk-I/O, Netzwerk) ausgelagert, Kern-Tick aber singlethreaded. | Echtes regionsbasiertes Multithreading: viele Regionen ticken parallel auf einem Thread-Pool. |
| Ressourcenverbrauch | Läuft sinnvoll schon auf wenigen Kernen; moderate Hardware genügt. | Profitiert erst ab vielen Kernen; empfohlen sind mindestens 16 echte CPU-Kerne. |
| Einsatzgebiet | Standard für nahezu alle Servertypen: Survival, Minispiele, Modpacks, Communitys, Lobbys. | Große, verteilte Server: SkyBlock, weitläufige SMP, sehr hohe Spielerzahlen mit kompatiblen Plugins. |
Die ehrliche Kurzfassung: Paper ist für die meisten Server die richtige Wahl. Folia gewinnt nur in dem speziellen Szenario, in dem sich viele Spieler über die Welt verteilen, die nötigen kompatiblen Plugins vorhanden sind und genügend starke CPU-Kerne zur Verfügung stehen.
Für welche Server eignet sich Folia?
Mögliche Nachteile und Herausforderungen
Plugin-Kompatibilität
Dies ist die mit Abstand größte Hürde. Folia ist kein Drop-in-Ersatz und „will break most public plugins". Der Server lädt nur Plugins, die ausdrücklich markiert wurden – durch den Eintrag folia-supported: true in der plugin.yml. Ohne diese Markierung wird ein Plugin gar nicht erst geladen. Das PaperMC-Projekt geht so weit zu sagen, es erwarte, dass „every single plugin that exists" zumindest irgendeine Anpassung benötigt, um unter Folia zu funktionieren. Wer auf ein großes, gewachsenes Plugin-Setup angewiesen ist, stößt hier schnell an Grenzen.
Entwicklungsaufwand
Plugins für Folia zu schreiben oder zu portieren erfordert echtes Umdenken. Entwickler dürfen sich nicht mehr auf einen Hauptthread verlassen, müssen die neuen Scheduler (Region/Entity/Global) korrekt einsetzen und ihre eigene Datenhaltung thread-sicher gestalten. Code, der von einer Region aus blind auf Daten einer anderen Region zugreift, führt zu Fehlern. Das hebt die Einstiegshürde für Entwickler spürbar an.
Migration bestehender Server
Eine bestehende Paper-Installation lässt sich nicht einfach „umstellen". In der Praxis bedeutet eine Migration: Plugins prüfen, inkompatible ersetzen oder neu entwickeln, Konfiguration und Hardware anpassen und ausgiebig testen. Berichte aus der Community sprechen davon, dass ein erheblicher Teil der Plugins durch Alternativen ersetzt werden muss und die Umstellung mit deutlichem Test- und Migrationsaufwand verbunden ist. Folia sollte daher als bewusste Architekturentscheidung verstanden werden, nicht als schnelles Performance-Upgrade.
Status-Hinweis: Folia gilt als fortgeschrittene, sich aktiv weiterentwickelnde Software. Wer es einsetzt, sollte mit höherer Komplexität und einem kleineren, spezialisierten Plugin-Ökosystem rechnen als bei Paper.
Installation von Folia
Die folgende Anleitung beschreibt die grundlegende Einrichtung. Sie ähnelt der von Paper, mit einigen Folia-spezifischen Besonderheiten.
java -versionLiegt die Version unter 21, installiere ein aktuelles JDK (z. B. Eclipse Temurin / Adoptium).
folia.jar.eula.txt mit folgendem Inhalt an: eula=true java -Xms8G -Xmx8G -jar folia.jar --noguiErsetze folia.jar durch den tatsächlichen Dateinamen. Stelle sicher, dass dein Terminal im Serververzeichnis steht.
plugins/-Ordner, die folia-supported: true in ihrer plugin.yml führen. Andere Plugins werden vom Server abgelehnt bzw. nicht geladen.Best Practices für maximale Performance
Häufig gestellte Fragen (FAQ)
1. Ist Folia ein Ersatz für Paper?
Nein. Folia ist kein Drop-in-Ersatz, sondern ein spezialisierter Fork. Für die große Mehrheit der Server bleibt Paper die richtige Wahl. Folia lohnt sich nur bei sehr hohen, über die Welt verteilten Spielerzahlen, passender Hardware und Folia-kompatiblen Plugins.
2. Laufen meine bestehenden Plugins unter Folia?
In aller Regel nicht ohne Anpassung. Folia lädt nur Plugins, die ausdrücklich mit folia-supported: true markiert sind. Praktisch kein gewöhnliches Paper-Plugin funktioniert unverändert; Autoren müssen ihren Code an die neuen Scheduler und das Thread-Modell anpassen.
3. Bedeutet Folia automatisch bessere Performance?
Nicht automatisch. Der Vorteil entsteht nur, wenn sich Spieler über die Welt verteilen, sodass viele unabhängige Regionen parallel ticken können. Sind alle Spieler am selben Ort, gibt es im Kern nur eine große Region und der Vorteil gegenüber Paper schwindet weitgehend.
4. Wie viele CPU-Kerne brauche ich für Folia?
Das Projekt nennt als Richtwert mindestens 16 echte Kerne (keine logischen Threads). Wichtig ist außerdem eine solide Einzelkernleistung, da jede einzelne Region weiterhin auf nur einem Kern berechnet wird.
5. Welche Minecraft- und Java-Version benötigt Folia?
Folia benötigt mindestens Java 21 (JDK). Welche Minecraft-Version unterstützt wird, hängt von der jeweils aktuellen Build ab – lade stets eine zu deiner Zielversion passende Build von der offiziellen Download-Seite.
6. Was sind RegionScheduler, EntityScheduler und GlobalRegionScheduler?
Das sind die neuen Scheduler-APIs von Folia, die den klassischen BukkitScheduler ersetzen. Der RegionScheduler plant Aufgaben für die Region eines Ortes, der EntityScheduler für die Region einer Entität (z. B. eines Spielers), und der GlobalRegionScheduler für globale, ortsunabhängige Aufgaben.
7. Eignet sich Folia für kleine Server oder Minispiele?
Meist nicht. Kleine Communitys und lobby-zentrierte Minispiele bündeln Spieler auf engem Raum – genau die Situation, in der Folia kaum Vorteile bringt, während die Plugin-Einschränkungen voll zuschlagen. Hier ist Paper in der Regel besser geeignet.
8. Wie aufwendig ist die Migration von Paper zu Folia?
Deutlich aufwendiger als ein einfacher Versionswechsel. In der Praxis müssen inkompatible Plugins ersetzt oder neu entwickelt, die Konfiguration und Hardware angepasst und das gesamte Setup ausgiebig getestet werden. Plane Folia als bewusste Architekturentscheidung ein.
9. Ist Folia stabil und produktionsreif?
Folia wird vom PaperMC-Team aktiv entwickelt und gepflegt. Es richtet sich an fortgeschrittene Betreiber. Wer es produktiv einsetzt, sollte mit höherer Komplexität, einem kleineren Plugin-Ökosystem und der Notwendigkeit gründlicher eigener Tests rechnen.
10. Kann ein für Folia geschriebenes Plugin auch unter Paper laufen?
Das ist nicht automatisch der Fall. Es gibt jedoch Hilfsbibliotheken und Bestrebungen, plattformübergreifende Scheduler-APIs bereitzustellen, damit Entwickler ihre Plugins mit einem Codestand sowohl für Paper als auch für Folia pflegen können.
Fazit
Folia ist eine der spannendsten Entwicklungen im Minecraft-Server-Ökosystem der letzten Jahre, weil es ein jahrzehntealtes architektonisches Limit angeht: den Single-Thread-Haupt-Tick. Mit regionsbasiertem Multithreading verteilt Folia die Last unabhängiger Weltregionen parallel über mehrere CPU-Kerne und kann so – im richtigen Szenario – Spielerzahlen und Performance erreichen, die mit klassischer Server-Software auf einer einzigen Instanz kaum möglich wären. Genau deshalb betrachten viele Betreiber großer, verteilter Netzwerke regionsbasiertes Multithreading als die logische Zukunft performanter Minecraft-Server.
Gleichzeitig ist eine nüchterne Einordnung wichtig: Folia ist kein universelles Upgrade und kein Drop-in-Ersatz für Paper. Sein Nutzen steht und fällt mit der Spielerverteilung, der verfügbaren Mehrkern-Hardware und der Existenz Folia-kompatibler Plugins. Für die große Mehrheit der Server – kleine Communitys, Lobbys, dicht gedrängte Minispiele oder Setups mit umfangreichem klassischem Plugin-Stack – bleibt Paper die ausgereiftere und praktischere Wahl.
Die ehrliche Empfehlung lautet daher: Nutze Paper als Standard – und greife zu Folia gezielt dann, wenn dein Server genau dem Profil entspricht, für das es gebaut wurde: viele, weit verteilte Spieler, starke Mehrkern-Hardware und ein sorgfältig kuratierter, kompatibler Plugin-Stack. In diesem Fall ist Folia nicht nur eine Alternative, sondern ein echter Sprung in puncto Skalierbarkeit und moderner Multi-Core-Nutzung.
