QBCore, Qbox ou MRI Qbox: qual escolher para a sua cidade
As três são parentes e resolvem coisas diferentes. O que muda entre elas, os critérios que decidem de verdade e como testar antes de se comprometer.
Escolher a base é a decisão mais difícil de reverter em um servidor de FiveM. Plano de VPS você troca em um minuto, script você substitui, mas mudar de framework depois de meses significa refazer configuração, adaptar tudo o que foi instalado e, em muitos casos, perder o banco de dados.
As três opções do título são parentes: Qbox nasceu do QBCore, e MRI Qbox é construída sobre Qbox. A diferença está em quanto trabalho já vem pronto e em qual comunidade vai te ajudar quando algo quebrar.
A resposta rápida
Se você quiser o resumo antes da explicação:
| Se você... | Escolha |
|---|---|
| Quer o maior número de scripts prontos disponíveis | QBCore |
| Quer uma base mais moderna e vai desenvolver por cima | Qbox |
| Está começando e quer suporte e conteúdo em português | MRI Qbox |
| Já tem um desenvolvedor com experiência em uma delas | A que ele domina |
Esse último caso vale mais que todos os outros. Base que ninguém da sua equipe sabe mexer é problema garantido, por melhor que ela seja no papel.
QBCore
É o framework de roleplay mais usado do FiveM, e o mais antigo dos três.
O que ele tem de melhor é o ecossistema. Existe uma quantidade enorme de script pronto feito para QBCore, boa parte gratuita. Quando você procura "sistema de X para FiveM", a chance de encontrar uma versão QBCore é alta.
Junto com isso vem o volume de conteúdo: tutorial, vídeo, thread de fórum e gente que já passou pelo mesmo erro que você.
O contraponto é a idade. O código carrega decisões antigas, e parte dos resources da comunidade é mal otimizada. Não é culpa do framework em si, mas o efeito prático é que uma cidade QBCore montada sem critério fica pesada mais rápido.
Escolha QBCore se o seu diferencial vai vir de conteúdo, não de tecnologia, e você quer o caminho com mais material pronto disponível.
Qbox
Qbox nasceu como uma evolução do QBCore, com foco em modernizar o código e melhorar desempenho.
A proposta é padrão moderno. Ela se apoia no ecossistema ox, com
ox_lib, ox_inventory e oxmysql, que hoje é a referência técnica de boa
parte da comunidade de desenvolvimento do FiveM.
Ela mantém boa compatibilidade com o mundo QBCore, o que permite aproveitar muito do que já existe. Mas atenção: compatível não é idêntico. Alguns scripts funcionam direto, outros pedem ajuste, e há os que não funcionam.
O contraponto é o tamanho da comunidade. É menor que a do QBCore, o que significa menos tutorial pronto e mais necessidade de ler documentação.
Escolha Qbox se você tem quem desenvolva, se importa com desempenho desde o começo e prefere partir de uma base mais organizada.
MRI Qbox
MRI Qbox é uma base brasileira construída em cima do Qbox, com um conjunto de recursos já selecionados e um instalador que monta tudo sozinho.
A vantagem real é o tempo até a cidade estar de pé. Em vez de baixar
artefato, criar banco, importar .sql e instalar resource por resource, o
instalador faz o deploy inteiro. Mostramos o processo em
como criar um servidor de FiveM com a base MRI QBox.
A segunda vantagem é o idioma. Documentação, comunidade e suporte em português resolvem muito mais rápido do que traduzir dúvida para o inglês e esperar resposta num fórum internacional.
O contraponto é a dependência. Você fica atrelado às escolhas de quem mantém a distribuição: o que vem incluso, o ritmo de atualização e as regras de acesso, já que o instalador exige autenticação. É a troca clássica entre conveniência e controle.
Escolha MRI Qbox se você está começando, quer a cidade rodando rápido e prefere resolver dúvida em português.
Comparando lado a lado
| QBCore | Qbox | MRI Qbox | |
|---|---|---|---|
| Origem | Framework original | Evolução do QBCore | Base sobre Qbox |
| Scripts prontos disponíveis | Muitos | Bons, e reaproveita QBCore | Já vem com um conjunto |
| Código | Mais antigo | Mais moderno | Herda do Qbox |
| Instalação | Manual | Manual | Instalador automatizado |
| Comunidade | A maior | Média, técnica | Brasileira |
| Idioma do suporte | Inglês | Inglês | Português |
| Liberdade de customização | Total | Total | Dentro da distribuição |
| Curva de aprendizado | Média | Maior | A menor |
O critério que quase ninguém considera
Antes de comparar recurso, responda uma pergunta: quem vai dar manutenção nessa cidade daqui a três meses?
Se for você, escolha a base com mais material no idioma que você lê. Se for um desenvolvedor contratado, pergunte a ele antes de decidir, porque contratar alguém que precisa aprender a sua base custa em tempo e em bug.
E se a ideia é montar equipe depois, considere que encontrar gente que já sabe QBCore é bem mais fácil que encontrar gente que já sabe qualquer uma das outras.
O mito de que a base define o desempenho
Existe uma discussão eterna sobre qual framework é mais leve, e ela importa menos do que parece.
Nenhuma das três, sozinha, faz a sua cidade travar. O que faz travar é o que você instala em cima: script mal escrito, evento disparando em loop, resource esquecido ligado.
Uma cidade QBCore enxuta roda melhor que uma Qbox cheia de sistema desnecessário. Trocar de base para resolver lentidão quase nunca funciona, porque o problema volta assim que você reinstalar os mesmos scripts.
O caminho certo é medir. Escrevemos como fazer isso em como saber se a sua base precisa de otimização, com os dois comandos que apontam o resource culpado pelo nome.
E o vRP?
Vale citar, porque no Brasil ele é muito comum e não aparece nessa comparação.
O vRP é outra família de framework, bastante usada em bases nacionais como a ZIRIX. Se você está avaliando uma base pronta comprada ou baixada de comunidade brasileira, existe uma boa chance de ela ser vRP, e não QBCore.
Isso não é melhor nem pior, é outro caminho. Só não misture: script feito para QBCore não funciona em vRP sem adaptação, e vice-versa.
Como testar antes de decidir
Não escolha por comparação de internet. Suba as candidatas e entre nelas.
Dá para rodar dois servidores na mesma VPS e comparar lado a lado, e o passo a passo está em como rodar dois servidores de FiveM na mesma VPS.
No teste, olhe quatro coisas:
- Quanto tempo você levou para subir. Se travou já na instalação, isso vai se repetir em cada manutenção.
- A documentação. Abra a documentação e procure algo específico. Se você não achar, no dia do problema também não vai achar.
- A comunidade. Entre no Discord e veja se pergunta é respondida.
- Os scripts que você já pretende usar. Teste os principais antes, não depois.
Migrar depois custa caro
Vale terminar com o motivo de tudo isso importar.
Mudar de framework depois que a cidade tem jogadores significa refazer a configuração inteira, adaptar cada script, e lidar com um banco de dados que tem estrutura diferente. Na prática, a maioria dos servidores que tenta migrar acaba recomeçando do zero e perdendo os personagens.
Por isso vale gastar alguns dias testando agora, em vez de meses consertando depois.
Uma observação honesta: projeto de código aberto muda rápido. Recursos, compatibilidade e ritmo de atualização das três podem estar diferentes de quando este texto foi escrito, então confirme na documentação oficial de cada uma antes de fechar a decisão.
Depois de escolher
Com a base definida, o resto do caminho é o mesmo para todas:
- Como criar um servidor de FiveM do zero, no caminho manual
- Como iniciar o servidor pelo txAdmin, que também instala QBCore e Qbox por template
- Como escolher a VPS para o seu servidor, porque base boa em máquina pequena trava igual
E se a cidade ainda não tem onde rodar, os planos de FiveM da WyzeHost já vêm com proteção DDoS, cache externo e endereço personalizado inclusos.
