Como fazer o FiveM iniciar automaticamente ao ligar a VPS
Configure o servidor FiveM pra subir sozinho após reboot da VPS Linux usando systemd, com restart automático em crash e logs centralizados.
Servidor FiveM em produção tem uma regra simples: precisa estar online quando o jogador entra. VPS reinicia por update de kernel, queda de energia no datacenter, manutenção programada ou crash do próprio processo FXServer — e qualquer um desses eventos derruba o servidor se ele depender de você manualmente reabrir tmux e rodar o run.sh.
Este tutorial configura o servidor FiveM em uma VPS Linux pra subir sozinho no boot do sistema, reiniciar automaticamente em crash e ficar monitorado via systemd como qualquer serviço de produção. A persona é o owner que já tem o servidor instalado, sabe rodar o run.sh manualmente e quer eliminar a dependência de SSH ativa.
Tempo estimado: 15 a 20 minutos. Vale pra qualquer Linux com systemd (Ubuntu 22.04+, Debian 12+, AlmaLinux 9+).
Pré-requisitos
Você precisa de uma VPS Linux com FXServer já instalado e funcionando manualmente, acesso sudo (ou root), porta 30120 liberada no firewall e um conhecimento básico de editor de texto (nano ou vim). Se ainda não instalou o FiveM, faça isso antes — este tutorial assume que bash run.sh sobe o servidor sem erro.
Identifique os dados do seu setup atual antes de continuar — você vai precisar deles ao escrever o service unit:
/home/fivem/server /home/fivem/server-data fivem 30120 UDP/TCP Os caminhos acima são convenção — ajuste pra refletir sua estrutura real. Se você instalou tudo em /root/fivem, troque pelos seus caminhos em cada comando deste tutorial.
Criar usuário dedicado para o servidor
Rodar FiveM como root é vetor desnecessário de risco. Se você já tem um usuário separado, pule esta seção.
Crie o usuário do sistema sem shell interativo (não precisa fazer login direto nele):
sudo adduser --system --group --home /home/fivem --shell /bin/bash fivemO flag --system cria um UID baixo (abaixo de 1000), padrão pra contas de serviço. --group cria um grupo com o mesmo nome.
Mova os arquivos do FXServer pra dentro do home do novo usuário (se ainda não estiverem lá) e corrija o owner:
sudo chown -R fivem:fivem /home/fivemIsso garante que o processo rodando como fivem consegue ler os recursos, escrever logs e gravar cache.
Confirme que o usuário consegue rodar o servidor manualmente. Faça sudo -u fivem -i pra trocar pra ele e teste:
cd /home/fivem/server-data
bash ../server/run.sh +exec server.cfgSe subir sem erro, encerre com Ctrl+C. O service unit do systemd vai rodar exatamente esse comando — só que sem terminal preso.
Criar o service unit do systemd
O service unit é um arquivo de texto que descreve pro systemd como iniciar, parar e monitorar seu servidor. Vive em /etc/systemd/system/ com extensão .service.
Crie o arquivo do serviço:
sudo nano /etc/systemd/system/fivem.serviceCole a configuração abaixo, ajustando os caminhos pra refletir sua instalação:
[Unit]
Description=FiveM Server (FXServer)
After=network-online.target mysql.service
Wants=network-online.target
Requires=mysql.service
[Service]
Type=simple
User=fivem
Group=fivem
WorkingDirectory=/home/fivem/server-data
ExecStart=/home/fivem/server/run.sh +exec server.cfg
Restart=on-failure
RestartSec=10
StartLimitBurst=5
StartLimitIntervalSec=300
StandardOutput=journal
StandardError=journal
SyslogIdentifier=fivem
# Endurecimento opcional mas recomendado
NoNewPrivileges=true
PrivateTmp=true
ProtectSystem=full
ProtectHome=read-only
ReadWritePaths=/home/fivem
[Install]
WantedBy=multi-user.targetCada bloco tem um papel específico:
After=eRequires=mysql.servicegarante que o banco está pronto antes do servidor subir. Se você usa MariaDB, troque pormariadb.service. Se não tem banco, remova essas duas linhas.Restart=on-failurereinicia em crash mas não em saída limpa (Ctrl+C /systemctl stop).StartLimitBurst=5eStartLimitIntervalSec=300impedem loop infinito de restart consumindo CPU.- O bloco de endurecimento isola o processo do resto do sistema — se um recurso exploitável for carregado, o estrago fica contido.
A diretiva ProtectHome=read-only impede o processo de escrever em qualquer /home. Se você instalou o FiveM fora de /home (ex: /opt/fivem ou /root/fivem), ajuste ReadWritePaths= pra apontar pra essa pasta — caso contrário o servidor não consegue gravar cache nem logs e quebra silenciosamente.
Salve o arquivo (Ctrl+O, Enter, Ctrl+X no nano) e recarregue o systemd pra ele enxergar o novo unit:
sudo systemctl daemon-reloadSem esse comando, qualquer alteração em arquivos .service é ignorada até o próximo reboot.
Habilitar e iniciar o serviço
enable faz o serviço subir automaticamente a cada boot. start inicia agora. Os dois são separados de propósito — você pode querer um sem o outro.
Habilite o boot automático:
sudo systemctl enable fivem.serviceA saída mostra Created symlink /etc/systemd/system/multi-user.target.wants/fivem.service. Esse symlink é o que faz o systemd carregar o serviço a cada inicialização.
Inicie o serviço agora:
sudo systemctl start fivem.serviceO comando retorna imediatamente — o processo sobe em background. Não confunda silêncio com sucesso, verifique o status na próxima seção.
Verificar que está funcionando
Cheque o status do serviço:
sudo systemctl status fivem.serviceVocê deve ver Active: active (running) em verde, com PID, tempo de uptime e as últimas linhas de log. Se aparecer failed, vá direto pros logs detalhados.
Acompanhe os logs em tempo real:
sudo journalctl -u fivem.service -f-u filtra pelo unit, -f segue em tempo real (Ctrl+C pra sair). Você deve ver as mensagens típicas de boot do FXServer: Server started on port 30120, carregamento de recursos, etc.
Teste o restart automático provocando uma queda. Mate o processo manualmente:
sudo pkill -f FXServerEspere 10 segundos (o RestartSec=10 do unit) e rode systemctl status fivem.service de novo. O PID deve ser diferente — o systemd reiniciou sozinho. Os logs vão mostrar Stopped, Start request repeated too quickly (se for o caso) ou um novo Started.
Por último, o teste definitivo: reinicie a VPS.
sudo rebootAguarde 1-2 minutos, reconecte via SSH e rode systemctl status fivem.service. Se estiver active (running), sua configuração está completa — o servidor agora sobe sozinho em qualquer reboot futuro.
Resolução de problemas
Serviço fica em “activating” e nunca chega em “active”
O FXServer demora alguns segundos pra inicializar recursos. Se o serviço fica preso em activating (auto-restart), geralmente é falha no boot. Veja os logs completos do último ciclo:
sudo journalctl -u fivem.service -n 100 --no-pagerErros comuns: server.cfg com sintaxe errada, recurso faltando em resources/, porta 30120 já em uso por outro processo, ou MySQL ainda não está pronto. Se for o último caso, confirme com systemctl status mysql que o banco está active.
Servidor sobe mas ninguém consegue conectar
Verifique se a porta está realmente escutando:
sudo ss -tulpn | grep 30120Deve aparecer linha com users:(("FXServer",pid=...)). Se aparecer mas conexão externa falha, o problema é firewall — confirme regras de UDP+TCP na porta 30120 com sudo ufw status ou sudo iptables -L -n.
Logs muito verbosos enchendo o disco
Por padrão, o systemd-journal cresce sem limite. Edite /etc/systemd/journald.conf e descomente SystemMaxUse=500M e MaxRetentionSec=2week. Aplique com sudo systemctl restart systemd-journald. Isso mantém histórico suficiente pra debug sem detonar o disco.
Servidor reinicia em loop e satura a CPU
O StartLimitBurst=5 já protege contra isso, mas se você removeu essa linha por algum motivo, ative novamente. Pra parar o loop imediatamente sem editar o arquivo:
sudo systemctl stop fivem.service
sudo systemctl reset-failed fivem.serviceDepois investigue o motivo do crash nos logs antes de reabilitar.
Próximos passos
Com o servidor subindo sozinho, vale fortalecer o setup com:
- txAdmin como wrapper: configurar o
ExecStartpra iniciar o txAdmin em vez do FXServer direto. Você ganha painel web pra restart programado, gerenciamento de recursos e proteção extra contra crashes específicos do FXServer. - Backup automático do server-data: configurar
cronou outro timer do systemd pra exportar a pastaresources/e o banco MySQL pra storage externo diariamente. - Monitoramento de uptime: integrar com Uptime Kuma ou healthcheck externo apontando pra
http://seu-ip:30120/info.json— você recebe alerta quando o servidor cai mesmo antes dos jogadores reclamarem. - Limites de recurso por systemd: adicionar
MemoryMax=4GeCPUQuota=200%ao unit pra impedir que um vazamento de memória derrube a VPS inteira.
Se você está colocando o servidor em produção, uma VPS Hostini brasileira já vem com baixa latência pros jogadores nacionais e proteção DDoS — combinada com o auto-restart deste tutorial, seu uptime fica nas mãos da infraestrutura e não da sua disponibilidade pra dar bash run.sh.
Perguntas frequentes
Por que usar systemd em vez de tmux com cron @reboot?
systemd dá restart automático em crash, logs centralizados via journalctl, dependências de boot (espera o MySQL/Postgres subir antes), limite de recursos e watchdog. tmux + cron @reboot só sobe o processo uma vez — se cair no meio da madrugada, ninguém reinicia. Pra produção real é systemd; tmux serve pra desenvolvimento.
O servidor FiveM precisa rodar como root?
Não, e não deveria. Crie um usuário dedicado (`adduser fivem`), coloque os arquivos do servidor no home dele e configure o service unit com `User=fivem`. Roda em portas altas (30120 UDP/TCP padrão), então não precisa de root. Se um exploit comprometer o processo, o atacante fica preso no usuário fivem em vez do sistema inteiro.
Como faço o servidor esperar o MySQL subir antes de iniciar?
Adicione `After=mysql.service` e `Requires=mysql.service` na seção `[Unit]` do arquivo .service. Pra MariaDB use `mariadb.service`. Isso faz o systemd só iniciar o FiveM depois que o banco estiver disponível — evita o servidor subir quebrado, falhar conexão e entrar em loop de restart.
Posso usar txAdmin com systemd ao mesmo tempo?
Sim, e na verdade é o padrão recomendado. O serviço systemd inicia o txAdmin, e o txAdmin gerencia o processo FXServer internamente com auto-restart próprio em crash. Você ganha duas camadas: systemd garante que o txAdmin nunca morre, e txAdmin garante que o FXServer reinicia em crash de recurso ou hang.
Como vejo se o servidor reiniciou sozinho durante a noite?
Use `journalctl -u fivem.service --since '1 hour ago'` ou `systemctl status fivem` — a contagem de restarts e o timestamp do último start ficam visíveis. Pra histórico mais longo, `journalctl -u fivem.service --since yesterday | grep 'Started\|Stopped'` mostra todos os ciclos de boot do dia anterior.
O que fazer se o servidor entra em loop de restart e satura a CPU?
Adicione `StartLimitBurst=5` e `StartLimitIntervalSec=300` na seção `[Unit]`. Isso faz o systemd parar de tentar reiniciar depois de 5 falhas em 5 minutos, evitando consumir 100% de CPU em loop. Investigue o motivo via `journalctl -u fivem.service -n 200` antes de remover o limite.