QBCore vs ESX vs Qbox: qual framework escolher em 2026

Escolher o framework é a primeira grande decisão ao montar um servidor de FiveM, e também a mais difícil de reverter. O debate QBCore vs ESX está aberto há anos, e já faz um tempo que o Qbox entrou na conversa como terceira opção séria. Neste guia comparamos os três sem fanatismo: o que cada um oferece, no que realmente se diferenciam, para quem cada um serve e o que a sua escolha implica na hora de comprar scripts.

O que é um framework de FiveM e por que ele condiciona o seu stack?

Um framework de FiveM, como QBCore, ESX Legacy ou Qbox, é a base que gerencia personagens, dinheiro, empregos, itens e permissões, e quase todos os scripts que você instalar dependem dele. Cada um tem a sua própria API, então os scripts não são intercambiáveis sem adaptação.

Quando você instala o qb-core ou o es_extended, não está instalando “mais um script”, está instalando o sistema nervoso do seu servidor.

Um script de mecânico para QBCore chama funções como QBCore.Functions.GetPlayer, enquanto o equivalente para ESX usa ESX.GetPlayerFromId. Veja como muda algo tão simples quanto adicionar dinheiro a um jogador pelo 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)

Três frameworks, três APIs diferentes para a mesma operação. E isso se repete em cada sistema: a forma de definir empregos e cargos, a estrutura do banco de dados, o fluxo de seleção de personagem, o sistema de permissões e até o formato dos itens do inventário. Por isso o framework condiciona quais scripts você pode usar, quais tutoriais te servem, quais desenvolvedores podem te ajudar e até que comunidade de suporte você terá por trás.

Trocar de framework depois custa tempo e dinheiro, então vale dedicar uma tarde para decidir bem agora. Se você ainda está montando o servidor do zero, lembre que o framework é uma das primeiras peças do processo completo, do txAdmin ao server.cfg, e todo o resto é construído em cima dele.

A origem de cada framework

O ESX é o framework de RP mais antigo ainda vivo, o QBCore é o dominante atual e o Qbox é um fork moderno do QBCore construído sobre o ox_lib. Cada um nasceu de um momento diferente da comunidade de FiveM, e isso explica o estilo e o ecossistema de cada um.

ESX, o veterano

O ESX (es_extended) é o framework de RP econômico mais antigo entre os que continuam vivos. Nasceu na era de ouro dos servidores de roleplay e durante anos foi o padrão de fato. Sua versão moderna, o ESX Legacy, limpou boa parte do código antigo e hoje se apoia cada vez mais no ecossistema ox: ox_lib para utilitários e interface, ox_inventory como inventário e oxmysql como conector de banco de dados.

O grande ativo é o legado: há milhares de scripts, tutoriais e desenvolvedores que conhecem o ESX. O grande peso é esse mesmo legado: muito conteúdo antigo usa APIs obsoletas e a qualidade do código varia bastante.

QBCore, o dominante atual

O QBCore surgiu como evolução do antigo qbus e se tornou o framework de referência da cena anglófona. Seu ecossistema qb-* é enorme e muito coerente: qb-inventory, qb-garages, qb-policejob, qb-adminmenu e dezenas de recursos oficiais que cobrem quase tudo de que um servidor de RP precisa para abrir.

A estrutura do QBCore agrada porque é explícita: os dados do jogador ficam em PlayerData, os itens usam metadata de forma nativa (importante para objetos com estado, como armas com número de série) e a documentação oficial é razoável. A maior parte do mercado de scripts premium atual é desenvolvida primeiro para QBCore.

Qbox, a evolução sobre o ox

O Qbox é um fork da comunidade a partir do QBCore, nascido quando parte dos contribuidores decidiu modernizar a base sem carregar compatibilidade com código antigo. O núcleo, o qbx_core, é construído diretamente sobre o ox_lib e adota o ox_inventory como inventário padrão, com ênfase em desempenho, segurança e práticas modernas de Lua.

O detalhe-chave: o Qbox mantém uma ponte de compatibilidade com o QBCore, de modo que muitos scripts qb-* funcionam no Qbox sem mexer em nada ou com mudanças mínimas. Isso permite aproveitar o ecossistema do QBCore enquanto constrói o seu próprio.

Tabela comparativa: QBCore vs ESX vs Qbox

Na comparação, o QBCore oferece o maior ecossistema de scripts, o ESX Legacy o maior legado e uma comunidade grande, e o Qbox o núcleo mais bem otimizado. A tabela resume os cinco critérios que mais pesam na escolha.

Critério	ESX Legacy	QBCore	Qbox
Curva de aprendizado	Média; muita documentação, mas dispersa e com conteúdo obsoleto	Baixa-média; estrutura clara e docs oficiais decentes	Média; exige conhecer o ox_lib e conceitos mais modernos
Ecossistema de scripts	Enorme, porém envelhecido; o novo costuma vir via ox	O maior e mais ativo do mercado premium	Crescente; herda boa parte do QBCore via ponte
Desempenho	Bom se você usa o stack ox; regular com recursos antigos	Bom de base, depende muito dos recursos qb-* que você escolher	Muito bom; o núcleo é otimizado desde o design
Comunidade	Grande e experiente	A maior e mais ativa em nível global	Menor, mas técnica e em crescimento
Futuro	Estável, ritmo de desenvolvimento moderado	Muito consolidado, evolução contínua	Projeto moderno com direção técnica clara

Um aviso honesto sobre desempenho: o framework em si raramente é o gargalo. Um servidor ESX bem montado com recursos ox rende mais que um QBCore cheio de scripts mal otimizados. O que você vê no resmon depende muito mais da qualidade de cada recurso do que do logo do framework.

Para quem cada framework é indicado

Escolha o QBCore se está começando do zero ou vai comprar scripts premium, o ESX Legacy se a sua comunidade já vive nele, e o Qbox se prioriza desempenho e uma base moderna sobre o ox para um projeto de longo prazo.

Escolha o ESX se…

• Sua comunidade e as referências de RP que você acompanha usam ESX.
• Você já tem experiência com es_extended e com o ecossistema ox.
• Quer aproveitar anos de scripts, mapas e documentação acumulados, sabendo que terá de filtrar o obsoleto.

Escolha o QBCore se…

• Está começando do zero e quer o caminho com menos atrito: mais scripts disponíveis, mais tutoriais recentes, mais desenvolvedores no mercado.
• Pretende comprar scripts premium: a maioria das lojas desenvolve primeiro para QBCore.
• Valoriza um ecossistema oficial coerente, em que inventário, empregos e administração falam a mesma língua.

Escolha o Qbox se…

• Desempenho e limpeza de código importam mais que a quantidade bruta de recursos disponíveis.
• Você já trabalha com ox_lib e ox_inventory e quer um núcleo que os trate como cidadãos de primeira classe.
• Está montando um projeto de longo prazo e prefere uma base moderna, mesmo que exija um pouco mais de trabalho inicial. Cada vez mais scripts nativos para Qbox são publicados, além de tudo o que ele herda do QBCore.

E o standalone? Recursos standalone não dependem de nenhum framework e funcionam em qualquer um dos três. São a opção segura para utilitários, sistemas de interface ou mecânicas isoladas, e uma boa forma de reduzir o acoplamento do seu servidor.

Como migrar de um framework para outro: o que se salva e o que não?

Ao migrar de framework, salvam-se os recursos standalone, os mapas e MLOs, os veículos, as roupas, os peds e o stack ox, mas não os scripts atrelados ao framework nem o banco de dados, que precisam de adaptação ou migração. O que dá para reaproveitar:

• Recursos standalone: HUDs, sistemas de interface, utilitários e minigames que não tocam no framework migram sem mudanças.
• Mapas e MLOs: são cem por cento independentes do framework.
• Veículos, roupas e peds: os recursos de streaming de assets também não dependem do framework.
• O stack ox: se você usa ox_lib, ox_inventory e oxmysql, já tem meio caminho andado para transitar entre ESX Legacy e Qbox, porque ambos os adotam de forma natural.

O que não se salva: os scripts atrelados ao framework (empregos, lojas, gangues, facções) precisam da versão equivalente ou de adaptação manual, e o banco de dados exige migração porque ESX e QBCore estruturam usuários, personagens e itens de maneira diferente. O inventário costuma ser o ponto mais delicado, porque o formato dos itens e a metadata mudam entre sistemas; na nossa comparação do melhor inventário para FiveM explicamos essas diferenças em detalhe.

A rota com menos dor hoje é do QBCore para o Qbox: como é um fork com ponte de compatibilidade, boa parte dos seus recursos qb-* continuará funcionando enquanto você migra o resto por fases.

Um plano de migração por fases

Se decidir dar o salto, não faça tudo de uma vez numa sexta à noite. O processo que melhor funciona na prática é este:

1. Monte um servidor de testes com o novo framework e uma cópia do seu banco de dados. Nunca migre direto em produção.
2. Faça um inventário dos seus recursos: classifique cada um como standalone (migra como está), dependente do framework com versão equivalente disponível, ou dependente sem equivalente (será preciso adaptar ou substituir).
3. Migre os dados: personagens, dinheiro, veículos e itens. Existem ferramentas da comunidade para as rotas mais comuns, mas sempre revise o resultado à mão com várias contas de teste.
4. Teste com a staff por pelo menos uma semana: economia, empregos, inventário, polícia e todo fluxo que toque em dinheiro ou itens.
5. Anuncie a data, congele a economia por algumas horas e execute a troca com a possibilidade de voltar atrás se algo der errado.

Contado assim parece muito trabalho, e é. É exatamente por isso que vale escolher bem de primeira.

O impacto do framework na compra de scripts

Antes de comprar um script, confirme que ele declara suporte ao seu framework e inventário, que as dependências (como ox_lib ou oxmysql) estão cobertas e que tem manutenção ativa. “Compatível com QBCore” nem sempre significa compatível com Qbox. Em detalhe:

1. Compatibilidade declarada: a página do produto deve indicar explicitamente suporte ao seu framework e ao seu inventário. “Compatível com QBCore” nem sempre implica compatível com Qbox ou ox_inventory, embora cada vez mais desenvolvedores publiquem versões multi-framework que detectam o ambiente automaticamente.
2. Dependências: muitos scripts modernos exigem ox_lib ou oxmysql. Se o seu servidor ainda usa recursos antigos, anote isso antes de pagar.
3. Manutenção ativa: os frameworks evoluem e scripts abandonados quebram. Priorize lojas que ofereçam atualizações e suporte de verdade.

Prefira lojas que organizem os produtos por framework, com páginas dedicadas de scripts para QBCore, scripts para ESX e scripts para Qbox, para que você nunca compre às cegas. Com pagamento processado pelo Tebex, o download é imediato após a confirmação.

Qual framework escolher em 2026?

Não existe vencedor universal. O QBCore é a opção padrão para quem começa em 2026 pelo tamanho do ecossistema; o ESX Legacy continua sólido se a sua comunidade vive nele; e o Qbox é a aposta técnica para projetos de longo prazo que valorizam uma base moderna sobre o ox.

Os três são frameworks maduros com os quais dá para construir um grande servidor. A diferença real está na qualidade dos recursos que você instala por cima e no cuidado com que monta a sua economia e a sua administração. Escolha o que escolher, faça do framework uma decisão estratégica e não uma jaula.