QBCore vs ESX vs Qbox: qué framework elegir en 2026

Elegir framework es la primera gran decisión al montar un servidor de FiveM, y también la más difícil de revertir. El debate qbcore vs esx lleva años abierto, y desde hace un tiempo Qbox se ha sumado a la conversación como tercera opción seria. En esta guía comparamos los tres sin fanatismos: qué ofrece cada uno, en qué se diferencian de verdad, a quién le conviene cada cual y qué implica tu elección cuando llegue el momento de comprar scripts.

¿Qué es un framework de FiveM y por qué condiciona tu stack?

Un framework de FiveM, como QBCore, ESX Legacy o Qbox, es la base que gestiona personajes, dinero, trabajos, items y permisos, y casi todos los scripts que instales dependen de él. Cada uno tiene su propia API, así que sus scripts no son intercambiables sin adaptación.

Cuando instalas qb-core o es_extended no estás instalando “un script más”, estás instalando el sistema nervioso de tu servidor.

Un script de mecánico para QBCore llama a funciones como QBCore.Functions.GetPlayer, mientras que su equivalente para ESX usa ESX.GetPlayerFromId. No son intercambiables sin adaptación. Mira cómo cambia algo tan simple como añadir dinero a un jugador desde el servidor:

-- QBCore
local Player = QBCore.Functions.GetPlayer(source)
Player.Functions.AddMoney('bank', 500)

-- ESX Legacy
local xPlayer = ESX.GetPlayerFromId(source)
xPlayer.addAccountMoney('bank', 500)

-- Qbox
local player = exports.qbx_core:GetPlayer(source)
player.Functions.AddMoney('bank', 500)

Tres frameworks, tres APIs distintas para la misma operación. Y esto se repite en cada sistema: la forma de definir trabajos y rangos, la estructura de la base de datos, el flujo de selección de personaje, el sistema de permisos y hasta el formato de los items del inventario. Por eso el framework condiciona qué scripts puedes usar, qué tutoriales te sirven, qué desarrolladores pueden ayudarte y hasta qué comunidad de soporte tendrás detrás.

Cambiar de framework más adelante cuesta tiempo y dinero, así que merece la pena dedicar una tarde a decidir bien ahora. Si todavía estás montando el servidor desde cero, ten presente que el framework es una de las primeras piezas del proceso completo, desde txAdmin hasta el server.cfg, y todo lo demás se construye encima.

Un poco de historia: de dónde viene cada uno

ESX es el framework de rol más antiguo de los que siguen vivos, QBCore es el dominante actual en la escena angloparlante y Qbox es un fork moderno de QBCore construido sobre ox_lib.

ESX, el veterano

ESX (es_extended) es el framework de rol económico más antiguo de los que siguen vivos. Nació en la época dorada de los servidores de roleplay europeos y durante años fue el estándar de facto, especialmente en las comunidades hispanohablantes y francesas. Su versión moderna, ESX Legacy, limpió gran parte del código antiguo y hoy se apoya cada vez más en el ecosistema ox: ox_lib para utilidades e interfaz, ox_inventory como inventario y oxmysql como conector de base de datos.

Su gran activo es el legado: hay miles de scripts, tutoriales y desarrolladores que conocen ESX. Su gran lastre es ese mismo legado: mucho contenido antiguo usa APIs obsoletas y calidad de código muy variable.

QBCore, el dominante actual

QBCore surgió como evolución del antiguo qbus y se convirtió en el framework de referencia de la escena angloparlante. Su ecosistema qb-* es enorme y muy coherente: qb-inventory, qb-garages, qb-policejob, qb-adminmenu y decenas de recursos oficiales que cubren casi todo lo que necesita un servidor de rol al arrancar.

La estructura de QBCore gusta porque es explícita: los datos del jugador viven en PlayerData, los items usan metadata de forma nativa (importante para objetos con estado, como armas con número de serie) y la documentación oficial es razonable. La mayor parte del mercado de scripts premium actual se desarrolla primero para QBCore.

Qbox, la evolución sobre ox

Qbox es un fork comunitario de QBCore que nació cuando parte de sus contribuidores decidió modernizar la base sin arrastrar compatibilidad con código antiguo. Su núcleo, qbx_core, se construye directamente sobre ox_lib y adopta ox_inventory como inventario estándar, con énfasis en rendimiento, seguridad y prácticas modernas de Lua.

El detalle clave: Qbox mantiene un puente de compatibilidad con QBCore, de modo que muchos scripts qb-* funcionan sobre Qbox sin tocar nada o con cambios mínimos. Eso le permite aprovechar el ecosistema de QBCore mientras construye el suyo propio.

Tabla comparativa: QBCore vs ESX vs Qbox

En la tabla, QBCore ofrece el ecosistema de scripts más grande, ESX Legacy el mayor legado y una comunidad fuerte en español, y Qbox el núcleo mejor optimizado.

Criterio	ESX Legacy	QBCore	Qbox
Curva de aprendizaje	Media; mucha documentación pero dispersa y con contenido obsoleto	Baja-media; estructura clara y docs oficiales decentes	Media; requiere conocer ox_lib y conceptos más modernos
Ecosistema de scripts	Enorme pero envejecido; lo nuevo suele llegar vía ox	El más grande y activo del mercado premium	Creciente; hereda gran parte del de QBCore vía puente
Rendimiento	Bueno si usas el stack ox; regular con recursos antiguos	Bueno de base, depende mucho de los recursos qb-* que elijas	Muy bueno; el núcleo está optimizado desde el diseño
Comunidad	Grande, fuerte en Europa y en español	La más grande y activa a nivel global	Más pequeña pero técnica y en crecimiento
Futuro	Estable, ritmo de desarrollo moderado	Muy asentado, evolución continua	Proyecto moderno con dirección técnica clara

Una advertencia honesta sobre el rendimiento: el framework en sí rara vez es el cuello de botella. Un servidor ESX bien montado con recursos ox rinde mejor que un QBCore lleno de scripts mal optimizados. Lo que ves en resmon depende mucho más de la calidad de cada recurso que del logo del framework.

¿A quién le conviene cada framework?

Elige QBCore si empiezas de cero o vas a comprar scripts premium, ESX Legacy si tu comunidad hispanohablante o europea ya vive en él, y Qbox si priorizas el rendimiento y una base moderna sobre ox para un proyecto a largo plazo.

Elige ESX si…

• Tu comunidad objetivo es hispanohablante o europea y tus referentes de rol usan ESX.
• Ya tienes experiencia previa con es_extended y el ecosistema ox.
• Quieres aprovechar años de scripts, mapas y documentación acumulada, asumiendo que tendrás que filtrar lo obsoleto.

Elige QBCore si…

• Empiezas de cero y quieres el camino con menos fricción: más scripts disponibles, más tutoriales recientes, más desarrolladores en el mercado.
• Piensas comprar scripts premium: la mayoría de tiendas desarrollan primero para QBCore.
• Valoras un ecosistema oficial coherente donde inventario, trabajos y administración hablan el mismo idioma. Tenemos una guía completa de scripts QBCore imprescindibles para montar ese stack.

Elige Qbox si…

• Te importa el rendimiento y la limpieza del código por encima de la cantidad bruta de recursos disponibles.
• Ya trabajas con ox_lib y ox_inventory y quieres un núcleo que los trate como ciudadanos de primera clase.
• Montas un proyecto a largo plazo y prefieres una base moderna aunque implique algo más de trabajo inicial. Cada vez se publican más scripts nativos para Qbox, además de todo lo que hereda de QBCore.

¿Y standalone? Los recursos standalone no dependen de ningún framework y funcionan en cualquiera de los tres. Son la opción segura para utilidades, sistemas de interfaz o mecánicas aisladas, y una buena forma de reducir el acoplamiento de tu servidor.

Migrar de un framework a otro: qué se salva y qué no

Al migrar de framework se salvan los recursos standalone, los mapas y MLOs, los vehículos, la ropa, los peds y el stack ox, pero no los scripts atados al framework ni la base de datos, que necesitan adaptación o migración. Esto es lo que se puede reaprovechar:

• Recursos standalone: HUDs, sistemas de interfaz, utilidades y minijuegos que no tocan el framework migran sin cambios.
• Mapas y MLOs: son independientes del framework al cien por cien.
• Vehículos, ropa y peds: los recursos de streaming de assets tampoco dependen del framework.
• El stack ox: si usas ox_lib, ox_inventory y oxmysql, tienes medio camino hecho para moverte entre ESX Legacy y Qbox, porque ambos los adoptan de forma natural.

Lo que no se salva: los scripts atados al framework (trabajos, tiendas, bandas, facciones) necesitan su versión equivalente o una adaptación manual, y la base de datos requiere migración porque ESX y QBCore estructuran usuarios, personajes e items de forma distinta. El inventario suele ser el punto más delicado, porque el formato de los items y su metadata cambia entre sistemas; en nuestra comparativa del mejor inventario para FiveM explicamos esas diferencias en detalle.

La ruta con menos dolor hoy es QBCore hacia Qbox: al ser un fork con puente de compatibilidad, gran parte de tus recursos qb-* seguirán funcionando mientras migras el resto por fases.

Un plan de migración por fases

Si decides dar el salto, no lo hagas de golpe un viernes por la noche. El proceso que mejor funciona en la práctica es este:

1. Monta un servidor de pruebas con el framework nuevo y una copia de tu base de datos. Nunca migres directamente en producción.
2. Haz inventario de tus recursos: clasifica cada uno como standalone (migra tal cual), dependiente del framework con versión equivalente disponible, o dependiente sin equivalente (habrá que adaptarlo o sustituirlo).
3. Migra los datos: personajes, dinero, vehículos e items. Existen herramientas comunitarias para las rutas más comunes, pero revisa siempre el resultado a mano con varias cuentas de prueba.
4. Prueba con tu staff durante al menos una semana: economía, trabajos, inventario, policía y todo flujo que toque dinero o items.
5. Anuncia la fecha, congela la economía unas horas y ejecuta el cambio con posibilidad de volver atrás si algo sale mal.

Contado así parece mucho trabajo, y lo es. Esa es exactamente la razón por la que conviene elegir bien a la primera.

Cómo afecta el framework a la compra de scripts

Antes de comprar un script, comprueba que declare soporte para tu framework e inventario, que sus dependencias (como ox_lib u oxmysql) estén cubiertas y que tenga mantenimiento activo. “Compatible con QBCore” no siempre significa compatible con Qbox. En detalle:

1. Compatibilidad declarada: que la ficha del producto indique explícitamente soporte para tu framework y tu inventario. “Compatible con QBCore” no siempre implica compatible con Qbox u ox_inventory, aunque cada vez más desarrolladores publican versiones multi-framework que detectan el entorno automáticamente.
2. Dependencias: muchos scripts modernos requieren ox_lib u oxmysql. Si tu servidor todavía usa recursos antiguos, apúntalo antes de pagar.
3. Mantenimiento activo: los frameworks evolucionan y los scripts abandonados se rompen. Prioriza tiendas que ofrezcan actualizaciones gratuitas de por vida y soporte real.

En Cube Resources organizamos el catálogo exactamente por este criterio, con secciones dedicadas de scripts para QBCore, scripts para ESX y scripts para Qbox, de modo que nunca compres a ciegas. Los pagos se procesan a través de Tebex y la descarga es instantánea tras el pago.

¿Qué framework elegir en 2026?

No hay un ganador universal. QBCore es la opción por defecto para quien empieza en 2026 por el tamaño de su ecosistema; ESX Legacy sigue siendo sólido si tu comunidad y tus referentes viven ahí; y Qbox es la apuesta técnica para proyectos a largo plazo que valoran una base moderna sobre ox.

Los tres son frameworks maduros con los que se puede construir un gran servidor. La diferencia real la marcan la calidad de los recursos que instales encima y el cuidado con el que montes tu economía y tu administración.

Elijas lo que elijas, en nuestro catálogo de scripts para FiveM encontrarás recursos organizados por framework, con actualizaciones gratuitas de por vida, para que el framework sea una decisión estratégica y no una jaula.