QBCore vs QBox: What Server Owners Need to Know

If you're running a QBCore server, you've probably heard about QBox (qbx_core). It's positioned as the next evolution of QBCore — built by many of the same people, with a focus on better code quality and modern patterns. But should you migrate? Here's a grounded look at what's actually different.

What Is QBox?

QBox (officially qbx_core) is a community-driven framework that forked from QBCore with the goal of modernizing its architecture. It's not a completely different framework — it's an evolution. Much of the API surface is similar, and many QBCore resources work with QBox with minimal or no changes.

The key philosophy shift: QBox pushes developers toward ox_lib ecosystem integration, cleaner Lua patterns, and less reliance on the framework core for things that libraries handle better.

Key Differences

ox_lib as a First-Class Citizen

QBCore includes its own utility functions — menus, progress bars, notifications, etc. QBox delegates most of these to ox_lib, which is better maintained and more performant. This means less duplicated code and a more consistent developer experience.

Improved Player Data Handling

QBox reworks how player data is stored and accessed, with better use of state bags and cleaner APIs. The player object is more predictable, and there's less reliance on polling for data updates.

Overrides Instead of Forks

One of QBox's smartest decisions: instead of forcing you to fork and modify core resources, it provides an override system. You can change behavior without touching the source, which means you can update the framework without losing your customizations.

Better Inventory Integration

QBox is designed around ox_inventory as the default inventory system. While QBCore supports ox_inventory too, QBox's integration is tighter and more seamless.

Lua 5.4 by Default

QBox resources default to lua54 'yes' in their fxmanifest. This gives access to better integer handling, the bitwise operators, and generally cleaner Lua. QBCore resources often still run in 5.3 compatibility mode.

What Stays the Same?

More than you might expect:

• The core concept of player objects, jobs, gangs, and metadata
• Event naming patterns (though QBox encourages newer conventions)
• Database schema — QBox can work with existing QBCore databases
• Most QBCore resources work on QBox with minimal changes

Should You Migrate Now?

It depends on your situation:

Migrate if:

• You're starting a new server from scratch
• You're already heavily using ox_lib and ox_inventory
• You want to be on the "path forward" with community development
• You're willing to test thoroughly and have a staging environment

Stay on QBCore if:

• Your server is live with 100+ players and running stable
• You have heavily modified QBCore resources that would need rework
• You rely on paid resources that haven't added QBox support yet
• You don't have a staging environment to test the migration safely

The Smart Approach: Write for Both

This is what we do at Cryptic Scripts. Every resource we build uses runtime framework detection — a shared bridge module that checks which framework is running and provides wrapper methods. The resource code never calls QBCore or QBX directly.

-- shared/sh_framework.lua (simplified)
local Framework = {}

if GetResourceState('qbx_core') ~= 'missing' then
    Framework.name = 'qbox'
    Framework.core = exports.qbx_core
elseif GetResourceState('qb-core') ~= 'missing' then
    Framework.name = 'qbcore'
    Framework.core = exports['qb-core']:GetCoreObject()
end

function Framework:GetPlayer(source)
    if self.name == 'qbox' then
        return exports.qbx_core:GetPlayer(source)
    else
        return self.core.Functions.GetPlayer(source)
    end
end

return Framework

This means our customers don't have to choose. Install the resource, and it works with whatever framework you're running. When you're ready to migrate, your Cryptic Scripts resources will just work.

The Bottom Line

QBox is a genuine improvement over QBCore in code quality, architecture, and ecosystem alignment. But migration is a big decision for a live server. The safest path is to start writing framework-agnostic code now — whether you migrate next month or next year, your resources will be ready.

Every script from Cryptic Scripts supports both QBCore and QBox out of the box. No migration required on our end — and that's how we think all FiveM scripts should be built.