ESX vs QBCore vs Ox Core: Welches FiveM-Framework solltest du 2026 wählen?

Jede Woche fragt ein neuer Server-Betreiber dasselbe in Discord: „ESX oder QBCore?" Manchmal „oder Ox Core?" Die Antworten sind meist Stamm-bezogen — die Leute verteidigen das Framework, das sie zufällig betreiben. Dieser Post nimmt einen anderen Winkel: wofür jedes Framework wirklich gut ist, was seine echten Kosten sind, und was deine Community-Struktur dir darüber sagen sollte, welches du wählen solltest.

Die 30-Sekunden-Antwort

Wenn du nicht alles lesen willst:

• ESX Legacy — wähle das, wenn du das größte Script-Ökosystem, schnellsten Time-to-Launch und niedrigste Lernkurve willst. Der „sichere" Default für jeden neuen Server.
• QBCore — wähle das, wenn du ein Roleplay-Purist bist, der charakterzentriertes Design und ein anderes Gefühl als ESX will. Aktive Community, ordentliches Script-Ökosystem.
• Ox Core — wähle das, wenn du einen echten Entwickler im Team hast und die sauberste moderne Codebase willst. Kleineres Ökosystem, aber wächst rapide.

Alles weitere hier ist Detail, das diese Empfehlungen unterfüttert.

Was die Frameworks tatsächlich sind

ESX (Legacy)

ESX ist das Original. Der Name kommt von „Essential Mode Extended" — ein 2018er Add-on zum älteren Essential Mode. ESX Legacy ist der gewartete Fork (gestartet 2021), nachdem das Original-Repo eingeschlafen war. Stand 2026 ist es bei Version 1.13.x und wird aktiv von der esx-framework-Organisation gepflegt.

ESX ist um Jobs und Geld herum gebaut. Ein Spieler hat einen Job, ein Gehalt, Accounts (Bank, Geld, Black Money) und Grades. Das ganze Framework ist um dieses Modell geformt.

QBCore

QBCore (QBus Core) startete 2021 als „moderne Alternative" zu ESX. Nutzt ähnliche Konzepte, aber von Grund auf neu gebaut mit saubererem Code, besseren Events und stärkerem Fokus auf Charakter-Daten. Wird von der qbcore-framework-Organisation gepflegt.

QBCore ist um den Charakter herum gebaut. Ein Spieler hat eine citizenid, Metadata (Hunger, Durst, Stress), und das Framework gibt dir ein strukturiertes PlayerData-Objekt statt ESX' xPlayer. Geld ist nur ein Stück Metadata.

Ox Core

Ox Core (früher ox_core) ist das jüngste der drei, vom Overextended-Team — denselben Leuten, die ox_inventory, ox_lib, oxmysql gemacht haben. Von Grund auf in TypeScript gebaut, mit starker Typisierung, modernen Lua-Bindings via ox_lib und null Legacy-Ballast.

Ox Core ist um komponierbare Services herum gebaut. Das Framework gibt dir Primitive (Accounts, Groups, Metadata, Vehicles), und du baust dein Konzept von „Job" darauf. Mehr Arbeit upfront, dramatisch sauberer langfristig.

Ökosystem-Größe: das ist der echte Entscheidungsfaktor

Das Framework selbst ist 5 % von dem, was dein Server tatsächlich laufen lässt. Die anderen 95 % sind Third-Party-Scripts: Jobs, Phones, Garages, Inventare, Anti-Cheat, Mini-Games. Deine Framework-Wahl bestimmt, wie viel davon du ohne Anpassung nutzen kannst.

ESX-Ökosystem (2026)

• Tebex / Cfx.re Escrow-Listings mit Tag ESX: ~12.000+
• GitHub-Repos: tausende, gemischte Qualität
• Premium-Script-Anbieter mit aktivem ESX-Support: 50+
• Kompatible ODER konvertierbare Scripts: ~95 % des FiveM-Marktes

Wenn du ESX wählst, kannst du für nahezu alles, was dir einfällt, heute Nachmittag ein Script kaufen oder runterladen, und es wird wahrscheinlich funktionieren. Das ist der größte Grund, warum ESX immer noch dominiert.

QBCore-Ökosystem

• Tebex-Listings mit Tag QBCore: ~4.500+
• Premium QBCore-first Anbieter: 15-20
• Ökosystem-Trend: stabil bis leicht wachsend

QBCore hat mittlerweile seine eigene dezidierte Anbieter-Szene. Qualität ist generell höher als der ESX-Durchschnitt (weniger recyclter Müll), aber gelegentlich brauchst du eine ESX→QB-Konvertierung für etwas Nischiges.

Ox-Core-Ökosystem

• Native Ox-Core-Scripts: einige hundert
• Ox-Core-kompatibel (via ox_lib-Bindings): wachsend
• Anbieter-Commitment: hauptsächlich Overextended selbst + ein paar dedizierte Devs

Ox Cores Ökosystem ist real, aber klein. Wenn du Ox Core nimmst, rechne damit, 30-40 % deiner Scripts selbst zu schreiben oder in Auftrag zu geben. Für ein Dev-lastiges Team ist das spannend; für einen Solo-Betreiber ohne Coder ist es eine Falle.

Code-Qualität & Developer-Experience

Funktioniert alles. ESX ist ausführlich mit viel Indirektion (Events für Dinge, die direkte Calls sein könnten), kein Type-Safety. QBCore ist strukturierter mit Funktionen am Player-Objekt — etwas mehr Tippen, aber leichter zu entdecken, was verfügbar ist. Ox Core ist am saubersten mit Callbacks statt Fire-and-Forget-Events; wenn du in TypeScript schreibst (was Ox Core unterstützt), bekommst du volles IDE-Autocomplete.

Performance

Im Idle und bei niedrigen Spielerzahlen performen alle drei Frameworks praktisch identisch (sub-0.10ms resmon). Der Unterschied zeigt sich bei Skalierung.

• ESX Legacy: läuft gut bis 200 Spieler. Manche Legacy-Event-Patterns sind ineffizient unter Last.
• QBCore: ähnlich wie ESX. Das Metadata-System kann zum Hotspot werden, wenn du viele Custom-Keys speicherst.
• Ox Core: messbar schlanker dank ox_inventorys gebatchter Updates und ox_libs modernen Primitiven. Beste Wahl für 500+ Slot-Ambitionen.

Dabei: deine Scripts begrenzen den Server lange bevor das Framework es tut. Ein einziges schlecht geschriebenes Job-Script mit einer 200-ms-DB-Query tut mehr weh als die Framework-Wahl.

Spieler-sichtbare Unterschiede

Spieler wissen nicht, welches Framework du fährst. Sie bemerken:

• Identifier-System — ESX nutzt License-Prefix-Identifiers. QBCore nutzt citizenids. Ox Core nutzt charid. Framework-Wechsel bedeutet neue IDs für alle, außer du migrierst manuell.
• Multi-Character — QBCore hat das eingebaut. ESX und Ox Core brauchen ein Addon (die meisten ESX-Server nutzen esx_multicharacter).
• Status-System — QBCore liefert Hunger/Durst/Stress mit. ESX hat Basis-Needs als Add-Ons. Ox Core überlässt es dir.

Migrationskosten (falls du schon eines fährst und überlegst zu wechseln)

Ehrlich: fast niemand vollendet eine Framework-Migration. Sie fangen an, fahren beide Frameworks „temporär" parallel zum Testen, verlieren 30 % der Spieler an das Chaos und brechen die Migration nach 8 Wochen ab. Das richtige Framework beim ersten Mal wählen ist viel günstiger als „migriere, wenn's falsch ist".

Wahl nach Community-Typ

ESX wenn: erster Server, kein dedizierter Entwickler, größter Script-Katalog, DACH/EU Roleplay, „klassisches GTA-RP"-Gefühl.

QBCore wenn: US/EN-Community, Multi-Character out-of-the-box, charakter-first-Design, du den Code-Stil besser findest.

Ox Core wenn: full-time Entwickler im Team, custom RP-Konzept das das „Job/Geld"-Modell sprengt, TypeScript und modernes Tooling, OK damit 30-40 % selbst zu schreiben.

Der häufigste Fehler

Leute wählen QBCore oder Ox Core, weil „es besser als ESX ist" — ohne das kleinere Script-Ökosystem einzukalkulieren. Drei Wochen später merken sie, dass das Garage-Script, das sie wollten, ESX-only ist; das Phone, das sie wollten, konvertiert werden muss; der Job, den sie geplant haben, Custom-Entwicklung braucht. Sie entweder: (a) portieren schmerzhaft alles, oder (b) wechseln still zu ESX und versuchen, es nicht zu erwähnen.

„Bestes Framework" zählt nicht, wenn du keinen Server ausliefern kannst. „Bestes Framework, mit dem ich praktisch launchen kann" heißt meist ESX.

Was wir devCon-Kunden empfehlen

Wir testen unsere Scripts primär auf ESX Legacy (wo die meisten unserer Kunden sind). Alle unsere Produkte laufen auf Legacy 1.13.x mit OneSync Infinity. Für QBCore liefern wir dedizierte QBCore-kompatible Versionen unserer meistgenutzten Scripts. Ox-Core-Support steht 2026 H2 auf der Roadmap.

Wenn du gerade deinen Stack wählst, unser Rat: starte mit ESX Legacy + ox_inventory + ox_lib + lb-phone. Diese Kombi lässt dich 95 % des Ökosystems nutzen, hat die geringste Launch-Friktion, und du kannst Ox-Core-Primitive immer später für neue Entwicklung dazunehmen, ohne das Funktionierende rauszureißen.

Alles zusammen

Keines dieser Frameworks ist „falsch". Alle drei treiben erfolgreiche, profitable RP-Server in 2026 an. Der Unterschied ist Passung: das Framework matchen mit deines Teams Skill, der Erwartungshaltung deiner Community und deiner Bereitschaft, Custom-Entwicklung zu machen.

Wähle ehrlich. Nicht basierend darauf, was jemand Lauteres als du sagt, sei „besser". Wähle basierend darauf, womit du tatsächlich bauen, ausliefern und in zwei Jahren noch warten kannst.

Weiterführende Artikel

• Beste ESX Scripts 2026: die Must-Have-Liste
• FiveM Optimierung: von 30 auf 60 FPS
• How to set up your own FiveM server