Honest, no-fluff comparison against the frameworks people are most likely already running. Every checkmark below is testable — open the source, run the resource, check the export.
Feature
Strata
Modular · 1st-party
QBCore
Community fork
ESX
Legacy · widespread
qbx_core
QB modernization
Runtime
Lua 5.4 default
Cerulean fxv2
Server-authoritative entities
Built-in anti-cheat helpers
Persistence
oxmysql only (no async)
Per-resource migrations
No JSON-file state
API surface
Versioned exports contract
Namespaced events
Typed callbacks
NetSync (server-auth state)
What's bundled
First-party inventory
First-party phone
First-party MDT
First-party housing
Cohesive UI language
All NUIs share design tokens + a typography stack
UI & NUIs
TypeScript NUIs
In-game interfaces written in TypeScript, not plain JS
Tailwind CSS styling
Vite build tooling
Shared design tokens
All NUIs pull from one token set — consistent colours, spacing, type
Operational
License
GPL-3.0
GPL-3.0
MIT
GPL-3.0
Active maintenance
Public roadmap
YesPartial · with caveatsNoAs of v1.0.0 · April 2026
When to pick QBCore
You already have a QB server with significant custom work. The migration cost outweighs the framework upgrade, and your team knows the QB exports surface cold.
When to pick ESX
You're running on extremely old artifacts you can't upgrade, or your scripts are deeply tied to ESX's identifier model. Stay where you are; don't half-migrate.
When to pick qbx_core
You want a modernized QB and you're committed to the QB ecosystem of community resources. qbx is the right call there — Strata isn't QB-compatible.
When to pick Strata
You're starting fresh, or your current framework feels like five forks duct-taped together. You want one design language across phone / MDT / inventory / admin, not five.
Still on the fence? Apply for a founder seat.
Strata is invite-only. The first ten operators get direct access to development — tell us about the server you're building and we'll review by hand.
