Qbox vs QBCore vs ESX: qual framework de FiveM escolher?

O framework é a base de um servidor de roleplay no FiveM. Ele é o dono do jogador: personagem, dinheiro, emprego, inventário, veículos e tudo o que vai para o banco de dados. Quase todo script que você adicionar depois conversa com ele, então escolher um é a decisão mais cara de desfazer.

Em 2026 existem três opções sérias: ESX Legacy, QBCore e Qbox. As três são gratuitas, open source e instaláveis em poucos cliques pelo txAdmin. Se você está na dúvida entre Qbox, QBCore ou ESX e quer saber qual framework escolher, este guia compara os três com honestidade, sem favorito.

Resumindo: escolha Qbox para um servidor novo se você curte o ecossistema da Overextended (ox) e quer a base de código mais modernizada. Escolha QBCore se quer a maior oferta de scripts e tutoriais prontos para qb. Escolha ESX Legacy se vai comprar scripts feitos primeiro para ESX ou se já conhece ESX.

O que um framework faz de verdade

Sem framework, um servidor de FiveM é um sandbox: o jogador spawna, dirige, sai e nada fica salvo. Um framework adiciona:

• Personagens e identidade – quem é o jogador e o que fica salvo sobre ele.
• Economia – dinheiro na mão, banco e outros tipos de dinheiro, com funções para adicionar e remover dinheiro com segurança no servidor.
• Empregos e cargos – polícia, SAMU, mecânico e as permissões de cada um.
• Inventário e itens – nativo ou por um resource de inventário separado.
• Uma API compartilhada – as funções que todo outro script chama, como "pegar esse jogador" ou "dar $500 para esse jogador".

Esse último ponto é o motivo de trocar ser difícil. Um script feito para ESX chama funções do ESX, e um servidor QBCore não tem essas funções.

Os três frameworks lado a lado

ESX Legacy

O ESX é onde os frameworks de roleplay no FiveM começaram, e ainda tem o maior acervo de scripts. O ESX antigo tinha fama de pesado e inseguro; o ESX Legacy é a versão mantida que corrigiu boa parte disso, removeu o jeito antigo de pegar o core object por evento e passou a usar padrões modernos.

Escolha ESX se:

• Os scripts pagos que você quer são feitos primeiro para ESX.
• Sua equipe já conhece ESX.
• Você está migrando um servidor ESX existente e não quer reescrever tudo.

Cuidado com: tutoriais antigos e scripts gratuitos que usam TriggerEvent('esx:getSharedObject', ...). Esse padrão está depreciado; resources ESX modernos carregam o core pelo @es_extended/imports.lua. Se um script ainda usa o evento antigo, considere que ele está abandonado.

QBCore

O QBCore chegou em 2021 com uma estrutura mais organizada: um único core object, métodos Player.Functions consistentes e um conjunto de resources qb-* combinando para empregos, casas, celular e mais. Rapidamente virou o framework mais popular para servidores novos, e hoje a maioria dos vendedores de scripts lança uma versão QBCore.

Escolha QBCore se:

• Você quer a maior variedade de scripts prontos e específicos para o framework.
• Você aprende melhor com tutoriais no YouTube e tópicos de fórum; tem mais conteúdo de QBCore do que de qualquer outro.
• Você pretende usar principalmente resources prontos em vez de programar os seus.

Cuidado com: misturar resources qb-* antigos e novos de anos diferentes. Muitos resources gratuitos nunca foram atualizados, e incompatibilidade de versão com o qb-core é uma fonte comum de erros.

Qbox

O Qbox começou como um fork do QBCore em setembro de 2022 com um objetivo: manter a estrutura conhecida do QBCore, mas modernizar a parte interna. Ele se apoia bastante no stack da Overextended – ox_lib para UI e utilitários, ox_inventory para itens e ox_target para interações – e expõe o core por exports diretos em vez de um objeto compartilhado.

A maior vantagem prática é o bridge do QBCore: segundo a documentação do Qbox, a maioria dos scripts QBCore roda no Qbox sem alterações, com algumas exceções. Você ganha um core moderno sem abrir mão do mercado de scripts QBCore.

Escolha Qbox se:

• Você está começando um servidor novo e quer a base de código mais modernizada.
• Você curte o ecossistema ox (ox_inventory, ox_target, ox_lib).
• Você quer compatibilidade com QBCore hoje e código nativo mais limpo nos scripts que você mesmo escrever.

Cuidado com: o requisito de banco de dados. O Qbox precisa de MariaDB 10.9 ou mais recente e não suporta MySQL. Os scripts que mexem a fundo nas partes internas do QBCore, em vez das funções públicas, são os que mais provavelmente vão precisar de ajustes.

A mesma tarefa nos três frameworks

Aqui vai uma função server-side que dá $500 em dinheiro para um jogador. Ela mostra como é programar em cada framework.

ESX Legacy (com @es_extended/imports.lua no seu 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

Os três funcionam bem. A diferença é de estilo: o ESX usa um objeto xPlayer, o QBCore usa Player.Functions e o Qbox prefere chamar exports direto. Repare no argumento reason no QBCore e no Qbox; ele vai parar nos seus logs, o que faz diferença na primeira vez que você investigar um exploit de dupe.

Nota de segurança: alterações de dinheiro sempre precisam acontecer no servidor, e é o servidor que decide o valor. Nunca confie em um valor enviado pelo client, senão um cheater consegue disparar seu evento com o número que quiser.

Quais scripts vão funcionar?

Normalmente é isso que decide:

• Scripts pagos de vendedores conhecidos quase sempre suportam ESX e QBCore, muitas vezes por uma opção no config. Muitos já listam Qbox também. Confira antes de comprar.
• Scripts QBCore no Qbox costumam funcionar graças ao bridge. Teste tudo que mexe com inventário, porque o Qbox usa ox_inventory em vez de qb-inventory.
• Scripts ESX ↔ QBCore não são intercambiáveis. Converter um significa trocar cada chamada ao framework, além das chamadas de inventário e notificação.
• Scripts standalone que não mexem com dinheiro, empregos ou inventário funcionam nos três.

Trocar de framework depois

Dá, mas encare como um projeto, não como coisa de uma tarde:

• QBCore → Qbox é a migração mais fácil. O bridge mantém a maioria dos resources rodando enquanto você migra. Você também vai sair do qb-inventory para o ox_inventory, o que significa converter as definições de itens e os inventários dos jogadores.
• ESX → QBCore/Qbox (ou o contrário) significa tabelas novas no banco, migração dos dados dos jogadores e reescrever ou substituir todo script que depende do framework.

Se estiver na dúvida, comece pelo framework para o qual seus scripts indispensáveis foram feitos.

Nossa recomendação

• Servidor novo, você se vira editando código: Qbox.
• Servidor novo, vai comprar a maioria dos scripts: QBCore ou Qbox; confira sua lista de scripts nos dois.
• Servidor ESX existente ou scripts feitos primeiro para ESX: continue no ESX Legacy.

Seja qual for a escolha, anote seu framework, inventário e resource de target e mantenha tudo consistente. Misturar qb-target com ox_target, ou dois inventários, quebra mais servidores do que qualquer escolha de framework. Quando gerar scripts com o BLDR, selecione seu framework e suas bibliotecas para o resultado já usar as chamadas certas desde o início.

Começando agora? Veja primeiro Como criar um servidor de FiveM, que mostra como instalar qualquer um dos três pelo txAdmin.

Perguntas frequentes

Qbox é melhor que QBCore?

O Qbox é uma continuação modernizada do QBCore, com um core mais limpo e integração mais forte com o ox, e roda a maioria dos scripts QBCore. Ser "melhor" depende dos seus scripts; se algum que você usa quebrar no bridge, o QBCore é a escolha mais segura.

O ESX morreu?

Não. O ESX Legacy continua sendo mantido e ainda tem um acervo grande de scripts. Está menos popular do que já foi para servidores novos, mas muitos servidores grandes rodam nele.

Dá para rodar scripts ESX e QBCore no mesmo servidor?

Não de forma confiável. Os dois frameworks gerenciam os mesmos dados do jogador de jeitos diferentes. Escolha um framework e converta os scripts para ele.

Qual framework é o mais rápido?

Para desempenho, o framework importa bem menos do que cada script individual. Um script mal feito com loop a cada frame custa mais do que a diferença entre frameworks. Meça com o resmon e o profiler do txAdmin.