Configurar o server.cfg do FiveM passo a passo

Par Benjamin D. · PDG

23 Gwengolo 2026 · Mis à jour le 23 Gwengolo 2026 · Lecture 6 min

Sumário

O server.cfg FiveM é o arquivo que define como o servidor se comporta desde o boot até o comportamento em tempo de execução: quais recursos carregam, como o OneSync sincroniza jogadores e quem tem permissão para usar comandos administrativos. Um arquivo mal estruturado é a causa mais comum de crashes, recursos que não iniciam e comandos que simplesmente não respondem no console.

Estrutura básica do server.cfg FiveM: o que não pode faltar

Antes de mexer em OneSync ou em permissões avançadas, vale revisar a base do arquivo. Todo server.cfg FiveM funcional precisa, no mínimo, de portas configuradas, licença válida, nome do servidor e a lista de recursos que serão carregados. A ordem das linhas importa: o FXServer lê o arquivo de cima para baixo, então um ensure chamado antes de sua dependência estar carregada gera erro no console.

# Rede e identidade
endpoint_add_tcp "0.0.0.0:30120"
endpoint_add_udp "0.0.0.0:30120"
sv_hostname "Meu Servidor RP"
sv_maxclients 64
sv_licenseKey "sua_chave_de_licenca_aqui"

# Recursos essenciais
ensure mapmanager
ensure chat
ensure spawnmanager
ensure sessionmanager
ensure basic-gamemode
ensure hardcap

A chave de licença (sv_licenseKey) é obrigatória e deve ser gerada na área de criação de servidores do CitizenFX. Sem ela, o servidor sobe localmente mas não fica visível na lista pública nem aceita conexões externas.

Para quem já tem a infraestrutura pronta e só precisa aplicar essas configurações num ambiente já preparado com painel de gestão, existe a opção de hospedagem FiveM, o que evita ter que montar manualmente o runtime do FXServer antes de chegar na parte de configuração propriamente dita.

Recursos (resources): ensure, start e ordem de carregamento

Cada recurso (resource) do FiveM é uma pasta dentro de resources/ contendo um fxmanifest.lua. O server.cfg controla quais dessas pastas são ativadas e em que ordem. Existem duas diretivas principais:

ensure: garante que o recurso esteja rodando, reiniciando-o se já estiver ativo. É a diretiva recomendada para a maioria dos casos.
start: inicia o recurso apenas se ele ainda não estiver rodando. Útil em scripts de reload parcial.

A ordem de carregamento é crítica quando existem dependências entre recursos, como um framework (ESX, QBCore) e os scripts que dependem dele. O padrão mais estável é carregar primeiro os recursos de base do FiveM, depois o framework, e só então os scripts de gameplay:

# Base do FiveM
ensure mapmanager
ensure chat
ensure spawnmanager
ensure sessionmanager

# Framework
ensure oxmysql
ensure es_extended
ensure esx_menu_default

# Scripts de gameplay
ensure esx_ambulancejob
ensure esx_policejob
ensure meu_script_customizado

Um erro comum é declarar ensure para um script que depende de outro recurso listado depois no arquivo. O console vai acusar erro de export inexistente ou de global não definida. Sempre que um recurso falhar ao iniciar, confira duas coisas: a sintaxe do fxmanifest.lua e se todas as dependências já foram garantidas (ensure) em linhas anteriores.

Também é possível organizar recursos em pastas de categoria (por exemplo [core], [jobs], [maps]) e usar ensure apontando para a pasta pai quando o servidor está configurado para varrer subpastas automaticamente. Isso não muda a lógica, apenas facilita a manutenção do server.cfg conforme a lista de recursos cresce.

OneSync: configuração para populações maiores e sincronização

O OneSync é o sistema responsável por sincronizar entidades (jogadores, veículos, peds, objetos) entre todos os clientes conectados, permitindo populações acima do limite tradicional de 32 jogadores. Sem OneSync ativo, cada jogador só enxerga as entidades processadas localmente pelo próprio jogo, o que quebra a sincronização em servidores com mais de 32 slots.

# Ativação do OneSync
onesync on

# Modo de população de NPCs e tráfego
onesync_population true

# Distância de streaming de entidades (ajuste conforme hardware)
onesync_forceMigration true

sv_maxclients 128

Existem variações do valor de onesync:

onesync off: desativado, recomendado apenas para servidores de teste com poucos jogadores.
onesync on: modo padrão recomendado para a maioria dos servidores em produção.
onesync legacy: modo de compatibilidade antigo, hoje praticamente obsoleto e não recomendado para novos projetos.

Um ponto que gera confusão: ativar OneSync não significa que o servidor vai automaticamente suportar mais slots com boa performance. O consumo de CPU sobe conforme o número de entidades sincronizadas (jogadores, veículos, peds), então é importante monitorar o uso de processamento ao escalar sv_maxclients junto com onesync_population. Servidores com scripts pesados de tráfego e peds tendem a se beneficiar de CPU com clock alto, já que grande parte da carga do OneSync é single-thread.

Vale revisar a documentação oficial do OneSync sempre que uma nova build do FXServer trouxer mudanças de comportamento nessas convars, já que o comportamento interno é atualizado com certa frequência.

Permissões, ACE e ajustes essenciais de segurança

O sistema de permissões do FiveM funciona por ACE (Access Control Entries) e principals. No server.cfg, isso é definido combinando add_ace, add_principal e, opcionalmente, um arquivo externo de permissões referenciado com exec.

# Define um grupo administrativo
add_ace group.admin command allow
add_ace group.admin command.quit allow
add_principal identifier.license:SUA_LICENCA_AQUI group.admin

# Bloqueia comandos sensíveis para o grupo padrão
add_ace group.user command.quit deny

# Carrega um arquivo separado de permissões
exec permissions.cfg

Separar as permissões em um arquivo dedicado (permissions.cfg) facilita a manutenção, principalmente em comunidades com vários níveis hierárquicos (admin, moderador, suporte). Isso evita ter que editar o server.cfg principal toda vez que um cargo muda.

Outros ajustes recorrentes

Além de recursos, OneSync e ACE, alguns ajustes finos costumam aparecer em praticamente todo server.cfg em produção:

# RCON para administração remota (defina uma senha forte)
rcon_password "senha_forte_aqui"

# Steam Web API Key, exigida por certos frameworks
set steam_webApiKey "sua_chave_steam"

# Limite de scripts em txAdmin ou monitoramento externo
set sv_scriptHookAllowed 0

# Mensagem de boas-vindas exibida no chat
set welcomeMessage "Bem-vindo ao servidor"

A senha de RCON merece atenção redobrada: é ela que permite executar comandos remotos no console do servidor, então deve seguir o mesmo padrão de uma senha administrativa qualquer, com caracteres variados e sem reaproveitamento de senhas usadas em outros serviços. Também é recomendável revisar periodicamente quais licenças estão associadas ao grupo admin, removendo identificadores de pessoas que não fazem mais parte da equipe.

Para quem gerencia o arquivo via painel Pterodactyl, a edição do server.cfg, o reinício do processo e a consulta ao console em tempo real ficam centralizados numa única interface, o que facilita testar mudanças de OneSync ou de recursos sem precisar acessar o sistema operacional diretamente. Quem prefere administrar essa camada por conta própria pode conferir as opções de VPS Pterodactyl ou explorar frameworks relacionados na página de Servidor RedM, já que RedM compartilha boa parte da estrutura de configuração do FXServer com o FiveM.

Conclusão

Um arquivo bem estruturado, com recursos na ordem certa, OneSync ajustado à população real do servidor e permissões ACE organizadas, evita boa parte dos problemas que aparecem no console durante o dia a dia. Revisar essas três frentes junto com a documentação oficial ajuda a manter o ambiente estável conforme novos recursos são adicionados.

FAQ

Por que meu recurso aparece como "couldn't start resource" no console?

Normalmente é falta de dependência carregada antes na ordem do server.cfg ou erro de sintaxe no fxmanifest.lua do recurso. Confira se todos os `ensure` das dependências vêm antes do recurso que falhou e valide o manifest linha por linha.

Ativar onesync on sozinho já resolve populações maiores?

Não. É preciso combinar `onesync on` com `sv_maxclients` ajustado e `onesync_population true`, além de monitorar o uso de CPU, já que entidades sincronizadas consomem processamento adicional conforme o número de jogadores cresce.

Como restringir comandos administrativos sem editar o server.cfg toda vez?

Separe as regras de ACE em um arquivo próprio, como permissions.cfg, e carregue-o com `exec permissions.cfg` no server.cfg principal. Assim as mudanças de cargo ficam isoladas desse arquivo secundário.