Qbox vs QBCore vs ESX: ¿cuál framework de FiveM elegir?

El framework es la base de un servidor de roleplay en FiveM. Es el dueño del jugador: su personaje, dinero, trabajo, inventario, vehículos y todo lo que se guarda en la base de datos. Casi todos los scripts que agregues después hablan con él, así que elegirlo es la decisión más cara de revertir.

En 2026 hay tres opciones serias: ESX Legacy, QBCore y Qbox. Las tres son gratis, open source y se instalan en pocos clics con txAdmin. Si te estás preguntando Qbox vs QBCore vs ESX, ¿cuál framework elegir?, esta guía los compara con honestidad, sin favoritos.

Versión corta: elige Qbox para un servidor nuevo si te sientes cómodo con el ecosistema de Overextended (ox) y quieres la base de código más modernizada. Elige QBCore si quieres la mayor oferta de scripts y tutoriales listos para qb. Elige ESX Legacy si vas a comprar scripts pensados primero para ESX o si ya conoces ESX.

Qué hace realmente un framework

Sin un framework, un servidor de FiveM es un sandbox: los jugadores aparecen, manejan y se van, y no se guarda nada. Un framework agrega:

• Personajes e identidad – quién es el jugador y qué se guarda de él.
• Economía – efectivo, banco y otros tipos de dinero, con funciones para sumar y quitar dinero de forma segura en el servidor.
• Trabajos y rangos – policía, EMS, mecánico y los permisos que vienen con cada uno.
• Inventario e items – integrado o a través de un resource de inventario aparte.
• Una API compartida – las funciones que llama cualquier otro script, como "obtener este jugador" o "darle $500 a este jugador".

Ese último punto es el motivo por el que cambiar es difícil. Un script hecho para ESX llama funciones de ESX, y un servidor QBCore no las tiene.

Los tres frameworks de un vistazo

ESX Legacy

ESX es donde nacieron los frameworks de roleplay en FiveM, y todavía tiene el catálogo de scripts más grande. El ESX viejo tenía fama de lento e inseguro; ESX Legacy es la versión mantenida que corrigió buena parte de eso, eliminó la vieja forma de obtener el core object por eventos y adoptó patrones modernos.

Elige ESX si:

• Los scripts de pago que quieres están hechos primero para ESX.
• Tu equipo ya conoce ESX.
• Estás migrando un servidor ESX existente y no quieres reescribir todo.

Ojo con: tutoriales viejos y scripts gratis que usan TriggerEvent('esx:getSharedObject', ...). Ese patrón está deprecado; los resources modernos de ESX cargan el core con @es_extended/imports.lua. Si un script todavía usa el evento viejo, considéralo abandonado.

QBCore

QBCore llegó en 2021 con una estructura más ordenada: un solo core object, métodos Player.Functions consistentes y un set de resources qb-* a juego para trabajos, casas, teléfonos y más. Rápidamente se volvió el framework más popular para servidores nuevos, y hoy la mayoría de los vendedores de scripts sacan una versión para QBCore.

Elige QBCore si:

• Quieres la mayor variedad de scripts listos y específicos para el framework.
• Aprendes mejor con tutoriales de YouTube e hilos de foros; hay más para QBCore que para cualquier otro.
• Planeas usar sobre todo resources ya hechos en lugar de programar los tuyos.

Ojo con: mezclar resources qb-* viejos y nuevos de distintos años. Muchos resources gratis nunca se actualizaron, y los desajustes de versión con qb-core son una fuente frecuente de errores.

Qbox

Qbox nació como un fork de QBCore en septiembre de 2022 con un objetivo: mantener la estructura conocida de QBCore pero modernizar lo de adentro. Se apoya mucho en el stack de Overextended – ox_lib para UI y utilidades, ox_inventory para items y ox_target para interacciones – y expone el core mediante exports directos en lugar de un objeto compartido.

Su mayor ventaja práctica es el bridge de QBCore: según la documentación de Qbox, la mayoría de los scripts de QBCore funcionan en Qbox sin cambios, con algunas excepciones. Tienes un core moderno sin renunciar al mercado de scripts de QBCore.

Elige Qbox si:

• Estás arrancando un servidor nuevo y quieres la base de código más modernizada.
• Te gusta el ecosistema ox (ox_inventory, ox_target, ox_lib).
• Quieres compatibilidad con QBCore hoy y código nativo más limpio para los scripts que escribas tú.

Ojo con: el requisito de base de datos. Qbox necesita MariaDB 10.9 o superior y no es compatible con MySQL. Los scripts que tocan a fondo las partes internas de QBCore, en lugar de sus funciones públicas, son los que más probablemente necesiten cambios.

La misma tarea en los tres frameworks

Esta es una función del lado del servidor que le da $500 en efectivo a un jugador. Muestra cómo se siente programar con cada framework.

ESX Legacy (con @es_extended/imports.lua en tu fxmanifest.lua):

local function giveCash(source, amount)
    local xPlayer = ESX.GetPlayerFromId(source)
    if not xPlayer then return end

    xPlayer.addMoney(amount)
end

QBCore:

local QBCore = exports['qb-core']:GetCoreObject()

local function giveCash(source, amount)
    local Player = QBCore.Functions.GetPlayer(source)
    if not Player then return end

    Player.Functions.AddMoney('cash', amount, 'gift')
end

Qbox (nativo):

local function giveCash(source, amount)
    exports.qbx_core:AddMoney(source, 'cash', amount, 'gift')
end

Los tres están bien. Las diferencias son de estilo: ESX usa un objeto xPlayer, QBCore usa Player.Functions y Qbox prefiere llamar exports directamente. Fíjate en el argumento reason en QBCore y Qbox; termina en tus logs, y eso importa la primera vez que investigues un exploit de duplicación.

Nota de seguridad: los cambios de dinero siempre tienen que ocurrir en el servidor, y el servidor tiene que decidir el monto. Nunca confíes en un monto enviado desde el cliente, o un tramposo podrá disparar tu evento con el número que quiera.

¿Qué scripts van a funcionar?

Normalmente esto es lo que define la elección:

• Los scripts de pago de vendedores establecidos casi siempre soportan ESX y QBCore, muchas veces con una opción en el config. Muchos ya incluyen Qbox también. Revísalo antes de comprar.
• Los scripts de QBCore en Qbox suelen funcionar gracias al bridge. Prueba todo lo que toque el inventario, porque Qbox usa ox_inventory en lugar de qb-inventory.
• Los scripts ESX ↔ QBCore no son intercambiables. Convertir uno implica reemplazar cada llamada al framework, además de las de inventario y notificaciones.
• Los scripts standalone que no tocan dinero, trabajos ni inventario funcionan en los tres.

Cambiar de framework más adelante

Se puede, pero planéalo como un proyecto, no como algo de una tarde:

• QBCore → Qbox es el cambio más fácil. El bridge mantiene funcionando la mayoría de los resources mientras migras. También vas a pasar de qb-inventory a ox_inventory, lo que implica convertir las definiciones de items y los inventarios de los jugadores.
• ESX → QBCore/Qbox (o al revés) implica tablas nuevas en la base de datos, migrar los datos de los jugadores y reescribir o reemplazar cada script que dependa del framework.

Si no estás seguro, empieza con el framework para el que están hechos los scripts que sí o sí necesitas.

Nuestra recomendación

• Servidor nuevo, te sientes cómodo editando código: Qbox.
• Servidor nuevo, vas a comprar casi todos los scripts: QBCore o Qbox; compara tu lista de scripts con ambos.
• Servidor ESX existente o scripts pensados primero para ESX: quédate en ESX Legacy.

Elijas el que elijas, anota tu framework, inventario y resource de target, y mantenlos consistentes. Mezclar qb-target y ox_target, o dos inventarios, rompe más servidores que cualquier elección de framework. Cuando generes scripts con BLDR, selecciona tu framework y tus librerías para que el resultado use las llamadas correctas desde el principio.

¿Eres nuevo en todo esto? Empieza con Cómo crear un servidor de FiveM, donde explicamos cómo instalar cualquiera de los tres con txAdmin.

Preguntas frecuentes

¿Qbox es mejor que QBCore?

Qbox es una continuación modernizada de QBCore, con un core más limpio y una integración más estrecha con ox, y corre la mayoría de los scripts de QBCore. Que sea "mejor" depende de tus scripts; si uno del que dependes se rompe con el bridge, QBCore es la opción más segura.

¿ESX está muerto?

No. ESX Legacy tiene mantenimiento y todavía cuenta con un gran catálogo de scripts. Es menos popular que antes para servidores nuevos, pero muchos servidores grandes lo usan.

¿Puedo usar scripts de ESX y QBCore en el mismo servidor?

No de forma confiable. Ambos frameworks manejan los mismos datos del jugador de maneras distintas. Elige un framework y convierte los scripts a ese.

¿Cuál framework es el más rápido?

En rendimiento, el framework importa mucho menos que cada script en particular. Un script mal hecho con un loop por frame cuesta más que la diferencia entre frameworks. Mide con resmon y el profiler de txAdmin.