QBOX (QBX) is a community-maintained fork of QBCore that introduces TypeScript-first development, performance improvements, and a cleaner architecture. While QBCore remains the established standard used by the vast majority of servers, QBOX aims to push the framework forward with modern development practices. If you're already on QBCore and considering a migration, or starting fresh and weighing options, this comparison covers the key differences.
| Feature | QBCore | QBOX (QBX) |
|---|---|---|
| Maturity | Very mature (years of production use) | Newer (2022+) |
| TypeScript support | Official types available | TypeScript-first design |
| Performance | Good (well optimized) | Improved (leaner architecture) |
| Script compatibility | Thousands of scripts | QBCore scripts (mostly compatible) |
| Community size | Very large | Growing (smaller) |
| Breaking changes | Infrequent | More frequent (active refactoring) |
| Migration from QBCore | N/A | Moderate effort required |
| Documentation | qbcore.gitbook.io (comprehensive) | QBOX docs (improving) |
| Active development | Very active | Very active |
| ESX compatibility | No (QBCore scripts only) | No (QBCore-based) |
QBOX emerged from the QBCore community as a fork that prioritizes TypeScript, performance, and modern coding standards. The original QBCore project accumulated technical debt over time, and QBOX aims to address this with a more opinionated, structured approach. The core team shares overlapping contributors with QBCore, giving it credibility, but QBOX remains a separate project with its own release cycle.
QBOX's TypeScript-first approach means better IDE support, fewer runtime bugs, and more maintainable code. Type definitions are built into the framework rather than bolted on. QBCore has added official TypeScript types, but its Lua-first heritage means the TypeScript experience isn't as seamless. For teams who want to write all server code in TypeScript, QBOX provides a more cohesive environment.
Most QBCore scripts run on QBOX with minimal changes — the core API is intentionally similar. The shared ecosystem of ox_lib, ox_inventory, and ox_target scripts works with both. However, scripts that depend on internal QBCore functions may need patching. Before migrating, audit your script list and check QBOX's compatibility notes for each resource.
Migrating from QBCore to QBOX involves updating your framework files, testing all scripts for compatibility, and adapting to QBOX's changed function signatures. For large servers with many custom scripts, this can take significant time. QBOX provides migration guides and the community is helpful, but it is a real undertaking — not a drop-in replacement.
If you're starting a new server in 2026 and your team is comfortable with TypeScript, QBOX is worth serious consideration. Its modern architecture and performance improvements are genuine advantages. For existing QBCore servers with many scripts, the migration cost usually outweighs the benefits unless you're doing a full server rebuild. QBCore remains the safer, better-documented choice for most server owners.
QBOX has technical advantages like TypeScript-first design and a cleaner architecture. However, QBCore's larger community and script library make it more practical for most server owners. QBOX is better suited for developers comfortable with TypeScript who want a modern foundation.
Migration requires moderate effort. Most scripts are compatible with minor changes, but you'll need to audit every resource and update any that use internal QBCore functions. Expect a few days of work for a typical server, longer for heavily customized setups.
No, QBOX is a QBCore fork and does not run ESX scripts. It maintains compatibility with the QBCore script ecosystem, not ESX.
Yes, QBOX is actively maintained with regular updates. The development team is responsive to issues and the project has strong community backing from QBCore veterans.