ESX vs. QBCore vs. Qbox: Welches FiveM-Framework passt?

Kurz gesagt: Wenn du einen neuen Server aufsetzt und auf die ox-Ressourcen (ox_lib, ox_inventory) bauen willst, ist Qbox im Moment die naheliegende Wahl. Läuft dein Server bereits stabil auf ESX und hängen viele eigene Skripte daran, bleib bei ESX, denn das Projekt wird aktiv gepflegt. QBCore lohnt sich vor allem dann, wenn du einen bestehenden QBCore-Server weiterbetreibst. Für neue Projekte im QB-Umfeld ist Qbox die bessere Basis.

Alle drei Frameworks lösen dasselbe Grundproblem: Sie verwalten Spieler, Charaktere, Geld, Jobs, Items und Fahrzeuge und geben anderen Ressourcen eine API dafür. Die Unterschiede liegen in der Pflege, im Ökosystem und darin, wie viel Altlast du mitschleppst. Wenn du gerade erst anfängst, lies vorher unseren Leitfaden FiveM-Server erstellen.

Die drei Frameworks im Vergleich

Die Angaben zu Releases und Aktivität stammen aus den offiziellen GitHub-Repositories. Stand: Oktober 2026.

Kriterium	ESX Legacy	QBCore	Qbox
Herkunft	Gestartet 2017, heute als ESX Legacy im Repo esx_core	Eigenständiges Framework, Core-Resource qb-core	Fork von QBCore, gegründet am 27. September 2022
Pflege (Stand: Oktober 2026)	Sehr aktiv: Release 1.16.0 am 11.10.2026, 1.16.4 am 18.10.2026	Letzte Commits im Core-Repo im August 2026, keine GitHub-Releases, Version im Manifest 1.3.0	Aktiv: qbx_core v1.24.0 am 22.08.2026, Commits bis Ende September 2026
Lizenz	GPL-3.0	GPL-3.0	GPL-3.0
Sprache und Architektur	Lua 5.4, oxmysql, eigene Bibliothek esx_lib; Jobs und Items liegen in der Datenbank	Lua 5.4, oxmysql; Jobs, Items und Fahrzeuge in Lua-Dateien unter shared/	Lua 5.4, setzt ox_lib und oxmysql voraus; Multicharacter, Queue und Multijob im Core
Ökosystem	Große Auswahl an esx_-Addons (Jobs, Shops, Garagen), eigene esx_inventory; ox_inventory wird offiziell unterstützt	Umfangreiches qb--Ressourcenset (Jobs, Phone, Housing, Inventar)	Eigene qbx_-Ressourcen plus Overextended-Ressourcen wie ox_inventory
Kompatibilität und Bridges	Keine Bridge zu QB-Skripten	Nutzt nur QB-Skripte nativ	Bridge-Layer stellt qb-core bereit; die meisten QBCore-Skripte laufen ohne Änderung
Lernkurve (Einschätzung)	Mittel; viele alte Tutorials beziehen sich auf veraltete ESX-Versionen	Niedrig für den Einstieg, viele Anleitungen	Mittel; du musst ox_lib und die ox-Konventionen kennen

Gemeinsam ist allen dreien mehr, als die Diskussionen in Discord-Servern vermuten lassen: Alle laufen mit Lua 5.4, alle greifen über oxmysql auf die Datenbank zu, und alle stehen unter GPL-3.0. Wenn du Skripte veränderst und weitergibst, gelten deshalb dieselben Lizenzpflichten. Der eigentliche Unterschied für deinen Alltag liegt in der API, die deine Skripte ansprechen, und in der Frage, welche fertigen Ressourcen du ohne Umbau einsetzen kannst.

ESX Legacy

ESX ist das älteste der drei Frameworks. Die heutige Linie heißt ESX Legacy und liegt im Repository esx-framework/esx_core. Dort findest du neben dem Core es_extended auch Grundressourcen wie Multicharacter, Identity, Skin, Notify und Progressbar. Das Projekt wird derzeit aktiv entwickelt: Im Oktober 2026 erschienen innerhalb einer Woche mehrere Releases von 1.16.0 bis 1.16.4.

Vorteile:

• Sehr viele vorhandene Skripte und Addons, auch auf dem freien Markt. Einen Überblick gibt unsere Seite zu FiveM-Mods und -Scripts.
• Jobs, Job-Grades und Items liegen in Datenbanktabellen. Du kannst sie per SQL oder Admin-Tool pflegen, ohne Lua-Dateien anzufassen.
• ox_inventory unterstützt ESX offiziell (setr inventory:framework "esx").
• Ausführliche Dokumentation für Core, Events, xPlayer und die Standard-Addons.

Nachteile:

• Durch das Alter des Projekts kursieren viele Skripte, die für ältere ESX-Versionen geschrieben wurden und mit Legacy Anpassungen brauchen.
• Kein Bridge-Layer für QBCore-Skripte. Was für QB geschrieben ist, musst du umschreiben oder eine ESX-Variante suchen.
• Seit es_extended auf esx_lib aufbaut, hast du eine weitere Kernabhängigkeit, die du bei Updates im Blick behalten musst.

QBCore

QBCore bringt ein breites Set an qb--Ressourcen mit: Polizei- und Ambulanzjob, Garagen, Häuser, Telefon, Inventar und vieles mehr. Gerade für Einsteiger ist das bequem, weil vieles aufeinander abgestimmt ist. Die GitHub-Organisation heißt inzwischen qbcore-fivem; die alte Adresse qbcore-framework leitet dorthin weiter.

Vorteile:

• Großes, zusammenhängendes Ressourcenpaket, mit dem du schnell einen spielbaren Server hast.
• Jobs, Items und Fahrzeuge in Lua-Dateien sind leicht versionierbar, etwa per Git.
• Viele Anleitungen und Drittanbieter-Skripte mit QB-Unterstützung.

Nachteile:

• Der Core wird langsamer weiterentwickelt als ESX und Qbox. Im Core-Repo gibt es keine GitHub-Releases, die letzten Commits stammen vom August 2026 und drehen sich vor allem um Repo-Pflege.
• ox_inventory bringt Bridges für ESX, Qbox, ox_core und ND mit, aber keine für QBCore. Wer ox_inventory will, landet praktisch bei Qbox.
• Einschätzung: Für neue Projekte gibt es kaum einen Grund, QBCore statt Qbox zu nehmen, weil Qbox QB-Skripte weitgehend mitträgt.

Qbox

Qbox ist laut eigener Dokumentation ein QBCore-Fork vom 27. September 2022. Ziel war, QBCore zu verbessern und dabei rückwärtskompatibel zu bleiben. Viele Ressourcen wurden seitdem überarbeitet und stützen sich auf Overextended-Ressourcen wie ox_lib und ox_inventory. Mit Overextended selbst ist das Qbox-Team nach eigener Aussage nicht verbunden.

Vorteile:

• Der Bridge-Layer stellt qb-core bereit. Laut FAQ laufen die meisten QBCore-Skripte ohne Änderung, solange sie die dokumentierte QB-API nutzen.
• Multicharacter, Warteschlange, Multijob/Multigang und Discord Rich Presence sind direkt im Core enthalten und konfigurierbar.
• Klare Regeln für Entwickler: keine direkten Zugriffe auf Core-Tabellen, keine Änderungen am Core, keine veralteten Funktionen.
• Eine Auswahl passender Ressourcen findest du in unserer Übersicht zu Qbox-Scripts.

Nachteile:

• Strengere Voraussetzungen: Qbox setzt MariaDB voraus (mindestens 10.9.0), MySQL und XAMPP werden ausdrücklich nicht unterstützt. Das betrifft auch deine Wahl beim FiveM-Server-Hosting.
• QB-Skripte, die direkt in Datenbanktabellen schreiben oder interne qb-core-Dateien nutzen, funktionieren nicht über die Bridge.
• Du arbeitest dich zusätzlich in ox_lib und die ox-Konventionen ein.

Migration: Was beim Wechsel bricht

Ein Framework-Wechsel ist bei einem laufenden Server ein größeres Projekt. Mach vorher ein vollständiges Backup von Dateien und Datenbank und teste auf einer Kopie, nie auf dem Live-Server.

QBCore zu Qbox

Das ist der einfachste Weg, weil Qbox genau dafür gebaut ist. Laut offizieller Umstiegsanleitung musst du unter anderem:

1. Job- und Gang-Grades in qbx_core/shared/jobs.lua und gangs.lua von Strings auf Zahlen umstellen.
2. ox_inventory einrichten und deine Inventardaten konvertieren (vorher sichern).
3. Die Kollation der Spalte players.citizenid prüfen, qbx_core.sql für die neue Tabelle player_groups ausführen und anschließend convertjobs in der txAdmin-Konsole starten.
4. Entscheiden, ob du die eingebauten Systeme (Multicharacter, Queue) nutzt oder abschaltest.

Skripte, die exports['qb-core']:GetCoreObject() aufrufen, laufen über die Bridge weiter. Ein direkter Export GetCoreObject aus qbx_core existiert nicht.

ESX zu QBCore oder Qbox

Hier gibt es keine Bridge. Du schreibst jedes Skript um oder ersetzt es. Diese Stellen brechen typischerweise:

• Core-Objekt und Exports: ESX-Skripte holen sich das Objekt über getSharedObject und arbeiten mit xPlayer. QB-Skripte nutzen das Core-Objekt aus qb-core und Player.PlayerData.
• Events: Aus esx:playerLoaded wird QBCore:Client:OnPlayerLoaded, aus esx:setJob wird QBCore:Client:OnJobUpdate. Die Parameter unterscheiden sich, also prüfe jeden Handler einzeln.
• Datenbankschema: ESX speichert Spieler in users und Fahrzeuge in owned_vehicles, Jobs und Items in eigenen Tabellen (jobs, job_grades, items). QBCore und Qbox nutzen players mit citizenid als Schlüssel und definieren Jobs und Items in Lua-Dateien. Spielerdaten musst du per eigenem Skript übertragen.
• Inventar: Wenn du schon ox_inventory unter ESX nutzt, bleibt dir das Inventarsystem beim Wechsel zu Qbox erhalten. Die Item-Definitionen und gespeicherten Inventare solltest du trotzdem prüfen.

Wie du einzelne Skripte konkret umbaust, zeigt unser Artikel FiveM-Code zwischen ESX und QBCore konvertieren.

Checkliste für deine Entscheidung

• Hast du schon einen laufenden Server? Bleib in der Regel bei deinem Framework. Ausnahme: Ein Umstieg von QBCore auf Qbox ist vergleichsweise günstig.
• Welche Skripte willst du unbedingt nutzen? Prüf bei jedem kaufpflichtigen oder freien Skript, welche Frameworks es offiziell unterstützt.
• Willst du ox_inventory? Dann kommen ESX oder Qbox infrage, QBCore nicht ohne Umbau.
• Welche Datenbank bietet dein Hoster? Für Qbox brauchst du MariaDB ab 10.9.0.
• Wie viel Lua kannst du selbst? Jede Framework-Wahl bedeutet, dass du Skripte anpassen wirst. Plane Zeit dafür ein.
• Woher kommen deine Skripte? Nutze seriöse Quellen, siehe Quellen für FiveM-Mods und -Scripts. Geleakte Ressourcen sind rechtlich und technisch ein Risiko, mehr dazu in Wird mein FiveM-Server gesperrt, wenn ich Leaks verwende?

FAQ

Laufen QBCore-Skripte auf Qbox?

In den meisten Fällen ja. Qbox liefert einen Bridge-Layer für die dokumentierte QBCore-API. Probleme machen laut Qbox-FAQ Skripte, die direkt auf Datenbanktabellen zugreifen, interne qb-core-Dateien nutzen oder Funktionen falsch verwenden.

Laufen ESX-Skripte auf QBCore oder Qbox?

Nein, nicht ohne Anpassung. Weder QBCore noch Qbox stellen eine offizielle ESX-Bridge bereit. Manche Drittanbieter-Skripte bringen eigene Bridges für mehrere Frameworks mit; das musst du pro Skript prüfen.

Wird ESX noch weiterentwickelt?

Ja. Das Repository esx_core hat im Oktober 2026 mehrere Releases erhalten, zuletzt 1.16.4 am 18. Oktober 2026 (Stand: Oktober 2026).

Kann ich ox_inventory mit QBCore nutzen?

Nicht offiziell. ox_inventory bringt Bridges für ESX, Qbox, ox_core und ND mit. Für QBCore gibt es keine. Wenn du aus dem QB-Umfeld kommst und ox_inventory willst, ist Qbox der vorgesehene Weg.