Für Serverbetreiber · 6 Min. Lesezeit · aktualisiert am 09.10.2026

ESX, QBCore oder Qbox: Welches Framework passt zu deinem Server?

ESX, QBCore und Qbox im fairen Vergleich: Was ein FiveM-Framework leistet, wo die Stärken der drei liegen und welches zu deinem ersten Server, einem Umzug oder deinem Dev-Team passt.

Bevor du den ersten Job einrichtest oder das erste Auto-Skript installierst, steht eine Entscheidung an, die deinen Server lange begleitet: das Framework. ESX, QBCore und Qbox sind die drei Namen, über die du fast sofort stolperst. In diesem Ratgeber erfährst du, was ein Framework überhaupt macht, wie sich die drei unterscheiden und wie du für deine Situation eine vernünftige Wahl triffst – ohne Glaubenskrieg.

Was ein Framework auf einem FiveM-Server macht

FiveM selbst liefert dir die Technik: Spieler verbinden sich, Ressourcen werden geladen, Client und Server reden miteinander. Was FiveM nicht mitbringt, ist die Spiellogik eines Roleplay-Servers. Genau diese Lücke füllt ein Framework. Es ist das Fundament, auf dem fast alle anderen Skripte aufbauen.

Typische Aufgaben eines Frameworks:

Charaktere: Spieler legen eine oder mehrere Figuren an, mit Namen, Geburtsdatum, Aussehen und Fortschritt.
Geld: Bargeld, Bankkonto, oft auch Schwarzgeld – inklusive Funktionen zum Auszahlen, Abziehen und Überweisen.
Jobs: Polizei, Rettungsdienst, Mechaniker und Co. mit Rängen, Gehalt und Rechten.
Inventar: Items, Gewicht, Benutzen, Tauschen – je nach Framework eingebaut oder als eigene Ressource.
Datenbank: Speichern und Laden aller Spielerdaten, meist über MySQL bzw. MariaDB.
Schnittstellen: Funktionen und Events, über die andere Skripte z. B. abfragen, welchen Job ein Spieler hat.

Der letzte Punkt ist der wichtigste für deine Entscheidung: Skripte werden fast immer für ein bestimmtes Framework geschrieben. Wenn du dich für eins entscheidest, entscheidest du dich damit auch für das passende Ökosystem an Ressourcen.

ESX: der Klassiker mit langer Geschichte

ESX gehört zu den ältesten Roleplay-Frameworks für FiveM. Die heute gepflegte Variante heißt ESX Legacy. Durch die lange Geschichte gibt es ein riesiges Angebot an Ressourcen – kostenlos und kostenpflichtig, gut und weniger gut.

Was du wissen solltest:

Viele ältere Tutorials und Skripte beziehen sich auf alte ESX-Versionen. Achte darauf, dass ein Skript zu ESX Legacy passt.
Die Struktur ist vielen Entwicklern vertraut, Hilfe findest du entsprechend oft.
Die Doku findest du unter docs.esx-framework.org.

ESX ist eine solide Wahl, wenn du auf bewährte Skripte setzen willst oder dein Team bereits ESX-Erfahrung hat.

QBCore: weit verbreitet mit vielen Skripten

QBCore ist später entstanden und hat sich schnell stark verbreitet. Viele Skript-Entwickler bieten ihre Ressourcen für QBCore an, oft parallel zu ESX. Das Framework bringt von Haus aus viele Grundfunktionen mit, sodass du recht schnell einen spielbaren Server hast.

Was du wissen solltest:

Die Standard-Ressourcen decken viele typische RP-Funktionen ab, was den Einstieg erleichtert.
Durch die große Verbreitung gibt es viele Community-Guides und Beispiele.
Die Doku findest du unter docs.qbcore.org.

QBCore passt gut, wenn du schnell starten und auf ein breites Skript-Angebot zugreifen willst.

Qbox: neuer, auf QBCore-Ideen aufgebaut

Qbox ist das jüngste der drei Frameworks. Es baut auf den Ideen von QBCore auf und bringt eine Kompatibilitätsschicht mit, damit viele QBCore-Skripte weiterhin laufen. Gleichzeitig setzt Qbox stark auf das Ökosystem von Overextended, etwa ox_lib und verwandte Ressourcen.

Was du wissen solltest:

Viele QBCore-Ressourcen funktionieren, aber nicht zwangsläufig alle ohne Anpassung. Teste vor dem Livegang.
Wer die ox-Ressourcen mag, findet hier ein stimmiges Gesamtpaket.
Die Doku findest du unter docs.qbox.re.

Qbox ist interessant, wenn du modern starten willst und trotzdem nicht auf das QBCore-Angebot verzichten möchtest.

Die drei im Vergleich

Die Tabelle ist bewusst allgemein gehalten. Alle drei Frameworks werden weiterentwickelt, Details ändern sich – prüfe im Zweifel die aktuelle Doku.

Aspekt	ESX (Legacy)	QBCore	Qbox
Ökosystem / Ressourcen	Sehr groß, viele ältere und neue Skripte	Groß, viele aktuelle Skripte	Wachsend, plus viele QBCore-Skripte über Kompatibilität
Lernkurve	Vertraut, aber Altlasten in alten Tutorials	Einsteigerfreundlich durch viele Standard-Ressourcen	Gut für alle, die QBCore oder ox_lib kennen
Community / Doku	Lange gewachsen, viel Wissen verteilt	Sehr aktiv, viele Guides	Kleiner, aber aktiv und modern dokumentiert
Kompatibilität	Skripte müssen für ESX sein	Skripte müssen für QBCore sein	Eigene Skripte plus viele QBCore-Skripte

Kein Framework ist objektiv „das beste“ – entscheidend ist, was zu deinem Team und deinen Skripten passt.

Entscheidungshilfe nach Situation

Dein erster Server

Nimm das Framework, zu dem du am leichtesten Hilfe bekommst. Schau dir die Skripte an, die du unbedingt haben willst (z. B. Telefon, Inventar, Garagen), und prüf, für welches Framework sie verfügbar sind. Wenn du Freunde oder Mitstreiter mit Erfahrung hast, ist deren Framework oft die beste Wahl – Wissen im Team ist mehr wert als jedes Feature.

Du willst umsteigen

Ein Wechsel ist kein Update, sondern ein Umbau. Spielerdaten, Items und Skripte müssen übertragen oder ersetzt werden.

Liste alle Ressourcen auf, die du nutzt, und prüfe, ob es sie für das neue Framework gibt.
Baue einen separaten Testserver mit Kopie der Datenbank.
Plane, wie du Charaktere, Geld und Inventare migrierst – oder ob ein Neustart (Wipe) ehrlicher ist.
Kündige den Wechsel früh in deiner Community an.

Von QBCore zu Qbox ist der Weg dank Kompatibilitätsschicht meist kürzer als ein Wechsel zwischen ESX und der QB-Welt. Trotzdem gilt: testen, testen, testen.

Du hast ein eigenes Dev-Team

Dann zählen weniger die fertigen Skripte als die Codebasis. Lass deine Entwickler die Doku und den Quellcode der Kandidaten anschauen. Fragen, die helfen: Wie sauber sind die Schnittstellen? Wie aktiv wird gepflegt? Wie gut lässt sich eigener Code sauber anbinden, ohne den Kern zu verändern?

Und was ist mit einem eigenen Framework?

Manche Server setzen auf ein Custom-Framework – komplett selbst geschrieben oder stark umgebaut. Das gibt dir volle Kontrolle, bedeutet aber auch: Fertige Skripte laufen meist nicht ohne Anpassung, und jede Funktion musst du selbst bauen und pflegen. Für ein erfahrenes Team kann das sinnvoll sein. Für den ersten Server ist es fast immer zu viel.

Skripte vorsichtig mischen

Viele Skripte werben mit Unterstützung für mehrere Frameworks oder bringen „Bridges“ mit. Das ist praktisch, hat aber Grenzen:

Ein Framework pro Server. ESX und QBCore gleichzeitig zu betreiben führt zu Chaos bei Geld, Jobs und Inventar.
Ein Inventar, ein Telefon, ein Target-System. Doppelte Systeme kollidieren schnell.
Abhängigkeiten prüfen. Lies die Installationshinweise, bevor du ein Skript einspielst.
Erst auf dem Testserver. Neue Ressourcen nie direkt auf dem Live-Server ausprobieren.

Weniger, aber gut abgestimmte Skripte machen einen stabileren Server als eine riesige Sammlung.

Framework auf GS2THETOP angeben

Wenn du deinen Server auf GS2THETOP einträgst, kannst du das Framework als Tag setzen. So können Spieler gezielt filtern – etwa wenn sie ESX-Server bevorzugen oder neugierig auf Qbox sind. Das Eintragen dauert etwa 30 Sekunden: Du gibst einfach deinen cfx.re-Join-Link ein, die Daten werden aus der öffentlichen Serverliste übernommen. Hier kannst du deinen FiveM-Server eintragen.

Welche Server bereits gelistet sind und wie sie sich präsentieren, siehst du in der FiveM-Übersicht. Weitere Tipps rund um deinen Server findest du im Ratgeber.

Fazit

ESX, QBCore und Qbox sind alle drei ernstzunehmende Grundlagen für einen Roleplay-Server. ESX punktet mit langer Geschichte und riesigem Angebot, QBCore mit großer Verbreitung und schnellem Einstieg, Qbox mit modernem Ansatz und QBCore-Kompatibilität. Wähle nach deinem Team, deinen Wunsch-Skripten und deiner Bereitschaft zu testen – und bleib dann dabei, statt ständig zu wechseln.