QBCore Framework Guide: Architecture, Install and Compatibility

QBCore is an open-source roleplay framework for FiveM. Its qb-core resource exposes shared player data, framework functions, commands and definitions that other QB resources can use. For a new server, use the official QBCore txAdmin recipe rather than treating the qb-core folder as a complete installation.

Key takeaways

• qb-core is the core resource, not a complete roleplay server by itself.
• The official Windows guide deploys the QBCore Framework popular template through txAdmin.
• The official recipe includes database setup and a wider set of QB resources.
• Compatibility depends on exact versions, dependencies, exports, SQL and resource order.
• No official source establishes QBCore as a universal performance winner; profile the complete stack you plan to run.

What QBCore provides

The QBCore Core Object is the shared interface used by many QB resources. The official documentation groups its capabilities around functions, player data, shared data, configuration and commands. A resource can request only the parts of the Core Object it needs, but its required API surface still has to match the core version on the server.

Shared definitions include jobs, gangs, items and vehicles represented in Lua tables. Core functions cover common framework operations, while player objects expose structured character data and player-related functions. Commands and permissions are part of the wider framework model. These are architectural capabilities, not proof that every server or resource will have the same performance or behavior.

Install QBCore with the official recipe

The current official Windows path uses FXServer's bundled txAdmin interface. In the recipe deployer, select the QBCore Framework popular template and follow the current QBCore installation guide. The recipe repository shows why installing only one ZIP is incomplete: it provisions the database and downloads a collection of resources around qb-core.

1. Prepare a supported FiveM server environment and a current FXServer artifact.
2. Start txAdmin and create a new deployment using the official QBCore popular recipe.
3. Provide the requested server key and database settings in the documented configuration flow.
4. Let the recipe deploy its SQL and resources instead of manually copying only qb-core.
5. Review the generated server.cfg, resource order and secrets before exposing the server.
6. Start the server and verify database connectivity, character creation, permissions and logs.

The database connection belongs in the server configuration used by oxmysql. Do not look for a generic database-connection field in qb-core/config.lua; that file is used for core and player configuration.

Add a QBCore resource safely

Before installing a job, inventory, target, phone or user-interface resource, record the exact version of qb-core and every related system it will integrate with. Then work through this boundary:

Check	What to verify
Framework API	Required Core Object functions, exports, events and player-data fields.
Dependencies	Inventory, target, menu, input, database and utility resources with exact versions.
Data	SQL migrations, table assumptions, item or job definitions and safe rollback.
Configuration	Permissions, locales, coordinates, feature flags and server-only secrets.
Order	Dependencies start before the resource and no duplicate replacement is active.
Validation	Allowed and denied roles, reconnects, restarts, client logs and server logs.

A product label that says QBCore is only the first compatibility signal. If the server replaces the recipe's inventory, target or menu layer, a script may require a documented adapter or configuration change. Apply database changes to a test copy first and keep a rollback that covers both files and data.

Who QBCore fits

QBCore is a reasonable candidate for a new server whose required resources explicitly support the current QB ecosystem, or an existing QB server that already uses its Core Object and data model. The choice becomes more expensive when a team has a large ESX data set, framework-specific scripts or undocumented custom events. In that case, inventory the migration surface before selecting a new framework.

Qbox began from the QBCore codebase and provides a compatibility bridge for many properly written QB resources, but the official Qbox documentation lists exceptions. Do not assume every QBCore script is a drop-in Qbox script. Likewise, do not migrate from ESX to QBCore based on a broad performance claim. Compare resource coverage, team knowledge, data conversion and the test plan.

QBCore, Qbox or ESX

• Stay with QBCore when your current resources and team already depend on documented QBCore APIs and the upgrade path is understood.
• Consider Qbox when you deliberately want its current APIs and recipe and can audit bridge exceptions resource by resource.
• Stay with ESX when your production data, integrations and operational knowledge are ESX-specific and there is no tested reason to migrate.

Use the framework comparison for a neutral decision method. When selecting from the paid FiveM scripts catalog, start with QBCore Scripts, confirm the requirements on the exact product page and stage the resource against a representative database before production.

Use the official QBCore recipe as the installation boundary

Start with the currently maintained QBCore txAdmin recipe and the official installation guide. A recipe provisions a baseline; it does not prove that an older third-party script supports the installed framework, database, inventory or target versions. Record the recipe commit and verify every added resource on staging before production.