Tutoriais de VPS
Montar um servidor dedicado de Satisfactory em VPS (2026): SteamCMD, novas portas, backups e atualizações automáticas
Monte um servidor dedicado de Satisfactory em um VPS Ubuntu 24.04 x86_64 com SteamCMD, cobrindo o App ID 1690800, as novas portas, o claim no Server Manager, systemd, backup e restauração e atualizações automáticas.
Se você quer jogar Satisfactory com amigos a longo prazo, abrir uma sessão temporária no PC de um jogador esbarra em um problema bem real: quando o host fica offline, a fábrica para; quando o host troca de computador, o save precisa ser movido; atualizações, backups e senhas de administração se acumulam em um computador pessoal. Depois de implantar um servidor dedicado em um VPS, o mundo pode funcionar 24 horas por dia, os jogadores podem entrar e construir a qualquer momento, e os administradores podem organizar de forma independente janelas de manutenção, backups e upgrades.
Este artigo usa como exemplo um VPS Ubuntu 24.04 x86_64, com o servidor Linux nativo oficial, SteamCMD e systemd, e percorre por completo a instalação, o claim do servidor, a abertura das novas portas, o backup, a restauração e as atualizações automáticas. Primeiro, um aviso sobre a mudança que mais facilmente pega quem copia tutoriais antigos: desde o Satisfactory 1.0, os antigos 15000/UDP e 15777/UDP não são mais usados; os padrões atuais exigem 7777/TCP, 7777/UDP e 8888/TCP.
A documentação oficial do servidor dedicado na Wiki da comunidade de Satisfactory lista o Steam App ID do servidor como 1690800. Ele suporta Windows e Linux nativos de 64 bits, mas apenas x86-64, não ARM.
Até agosto de 2026, o modelo de versão atual da Wiki oficial mostra o branch padrão como 1.2.3.1. Este artigo não coloca o número do patch no comando de instalação, porque o SteamCMD baixa a versão estável atual do branch padrão; o comando continuará funcionando para futuras atualizações menores.
| Item | Valor usado neste artigo |
|---|---|
| SteamCMD App ID | 1690800 |
| Sistema | Ubuntu 24.04 LTS x86_64 |
| Programa do servidor | FactoryServer.sh |
| Jogo e consulta | 7777/UDP |
| API HTTPS | 7777/TCP |
| Mensageria confiável | 8888/TCP |
Antes de comprar o VPS, confirme a arquitetura no console:
uname -m
lscpu | grep -E 'Architecture|Model name|Virtualization'
uname -m deve exibir x86_64. Se for aarch64 ou arm64, mesmo que o sistema consiga instalar o SteamCMD, ele não conseguirá executar o servidor oficial diretamente. A documentação oficial também observa especificamente que o modelo de CPU genérico kvm64 exposto por alguns VPS KVM pode impedir o servidor de iniciar; nesse caso, peça ao provedor para mudar para host-passthrough, para um modelo de CPU x86-64 mais recente, ou troque diretamente para uma instância que suporte conjuntos de instruções modernos, em vez de reinstalar o sistema repetidamente.
A escala das fábricas em Satisfactory cresce continuamente, e esteiras, trens, drones e uma grande quantidade de construções aumentam a pressão sobre CPU e memória. A documentação oficial indica um mínimo de 8 GB de memória e recomenda 16 GB para saves grandes ou mais de 4 jogadores. Na compra, também é preciso deixar margem para o Ubuntu, o SteamCMD, o cache de arquivos e as operações de manutenção.
| Cenário de uso | Configuração inicial recomendada | Disco NVMe | Observações |
|---|---|---|---|
| 2–4 jogadores, save novo | 4 vCPUs de alta frequência, 8 GB de memória | 50 GB | Consegue abrir o servidor, mas monitore a memória antes das fábricas grandes |
| 4–8 jogadores, save de longo prazo | 4–6 vCPUs de alta frequência, 16 GB de memória | 80 GB | Mais adequado para operação de longo prazo e backups online |
| Mais de 8 jogadores ou fábricas muito grandes | 6–8 vCPUs de alta frequência, 16–32 GB de memória | 100 GB+ | Requer expansão com base nos dados de monitoramento |
Esses são pontos de partida práticos, não garantias de número de jogadores ou de desempenho. O servidor de Satisfactory valoriza muito o desempenho de um único núcleo, então não compare apenas números de marketing como "8 núcleos" ou "16 núcleos". Quando a CPU compartilhada está muito sobrevendida, a carga total da máquina pode parecer baixa e o jogo ainda apresentar rubber-banding, atrasos na construção e travadas no autosave.
O data center deve ficar o mais próximo possível dos principais jogadores, e é preciso confirmar que o provedor permite servidores de jogos, suporta UDP, tem tráfego mensal suficiente e regras claras de tratamento de DDoS. Se você ainda não escolheu a máquina, pode primeiro consultar a configuração de VPS para servidores de jogos e escolha de linhas de rede.
Primeiro faça login no VPS via SSH, atualize o sistema e instale as dependências:
sudo apt update
sudo apt upgrade -y
sudo apt install -y curl ca-certificates tar lib32gcc-s1 lib32stdc++6 ufw
Não execute o servidor de jogo como root a longo prazo. Crie um usuário de sistema sem privilégios de administrador e prepare os diretórios de instalação e backup:
sudo adduser --system --group \
--home /home/satisfactory \
--shell /bin/bash satisfactory
sudo install -d -o satisfactory -g satisfactory /opt/steamcmd
sudo install -d -o satisfactory -g satisfactory /opt/satisfactory
sudo install -d -m 750 -o root -g satisfactory /var/backups/satisfactory
Verifique os diretórios e o espaço em disco:
id satisfactory
df -h /opt /home /var/backups
sudo -u satisfactory test -w /opt/satisfactory && echo 'install dir writable'
Se /opt e /home estiverem no mesmo disco de sistema pequeno, manter os backups nesse disco não vai proteger contra a exclusão do VPS ou falha do disco. Este artigo primeiro cria um ponto de recuperação local, mas depois ainda é preciso sincronizar os backups críticos para outra máquina ou armazenamento de objetos.
Baixe a versão Linux do SteamCMD da CDN oficial da Valve:
sudo -u satisfactory curl -fsSL \
https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz \
-o /opt/steamcmd/steamcmd_linux.tar.gz
sudo -u satisfactory tar -xzf \
/opt/steamcmd/steamcmd_linux.tar.gz \
-C /opt/steamcmd
sudo -u satisfactory /opt/steamcmd/steamcmd.sh +quit
A primeira execução atualiza o próprio SteamCMD. Quando terminar, confirme a propriedade do script e do diretório:
ls -l /opt/steamcmd/steamcmd.sh
sudo -u satisfactory test -x /opt/steamcmd/steamcmd.sh \
&& echo 'steamcmd ready'
Não baixe servidores empacotados de anexos de fóruns, drives na nuvem ou espelhos desconhecidos. O SteamCMD consegue obter diretamente os arquivos oficiais do servidor dedicado de forma anônima, então não há necessidade de colocar uma conta e senha pessoal da Steam no VPS.
Use o App ID 1690800 para instalar o branch padrão atual:
sudo -u satisfactory /opt/steamcmd/steamcmd.sh \
+force_install_dir /opt/satisfactory \
+login anonymous \
+app_update 1690800 validate \
+quit
Depois que o download terminar, verifique os arquivos principais:
sudo -u satisfactory test -x /opt/satisfactory/FactoryServer.sh \
&& echo 'FactoryServer ready'
du -sh /opt/satisfactory
ls -l /opt/satisfactory/FactoryServer.sh
Se o SteamCMD informar espaço em disco insuficiente, não se limite a limpar o cache de download e forçar a instalação. Saves, logs e futuras atualizações precisam de espaço extra; primeiro expanda o disco e garanta que os inodes também não estejam esgotados:
df -h
df -i
Antes de configurar o systemd formalmente, inicie uma vez em primeiro plano para ver os erros diretamente:
sudo -u satisfactory env HOME=/home/satisfactory \
/opt/satisfactory/FactoryServer.sh \
-Port=7777 \
-ReliablePort=8888
A primeira inicialização precisa gerar o diretório de configuração e inicializar o serviço, o que pode levar alguns minutos. Não force o encerramento só porque o terminal temporariamente não mostra nova saída. Em outra janela SSH, verifique o processo e as portas em escuta:
pgrep -af FactoryServer
sudo ss -lntup | grep -E ':7777|:8888'
curl -k https://127.0.0.1:7777
Devem aparecer TCP e UDP de 7777, e TCP de 8888. Se curl retornar que não encontrou a rota de API correspondente, um erro HTTP ou um erro JSON, isso não significa necessariamente uma falha; desde que a conexão TLS seja concluída e uma resposta do servidor seja recebida, a API HTTPS local está em escuta.
Quando confirmar que a inicialização foi bem-sucedida, pressione Ctrl+C no terminal que executa o servidor. A versão Linux recebe SIGINT e encerra normalmente. A documentação oficial alerta: uma saída normal não equivale a um autosave; antes de futuras manutenções, salve no jogo ou no Server Manager primeiro e depois pare o servidor.
As portas padrão atuais do Satisfactory são as seguintes:
| Porta | Protocolo | Uso | Entrada pública |
|---|---|---|---|
7777 | UDP | Tráfego de jogo e consulta | Obrigatório |
7777 | TCP | API HTTPS | Obrigatório |
8888 | TCP | Canal de mensageria confiável | Obrigatório |
Primeiro garanta que a regra de SSH exista e depois habilite o UFW:
sudo ufw allow OpenSSH
sudo ufw allow 7777/udp comment 'Satisfactory game and query'
sudo ufw allow 7777/tcp comment 'Satisfactory HTTPS API'
sudo ufw allow 8888/tcp comment 'Satisfactory reliable messaging'
sudo ufw enable
sudo ufw status numbered
Em seguida, vá ao grupo de segurança ou firewall na nuvem no console do provedor do VPS e adicione exatamente as mesmas três regras de entrada. O UFW do sistema e o grupo de segurança na nuvem são duas camadas de filtragem; faltar qualquer uma delas pode causar "o processo está normal, mas o mundo externo não consegue conectar". Você pode verificar camada por camada com a lista de verificação de portas, firewall e grupos de segurança.
Não continue copiando as regras 15000/UDP e 15777/UDP anteriores ao 1.0; elas não são mais usadas. E não abra todas as portas TCP/UDP só para facilitar.
Se um VPS executar várias instâncias de Satisfactory, você pode alterar as portas, por exemplo:
/opt/satisfactory/FactoryServer.sh \
-Port=7778 \
-ReliablePort=8889
A porta pública do Port padrão deve coincidir com a porta de escuta do servidor; não dá para simplesmente usar NAT comum para redirecionar a 7778 externa para a 7777 interna à vontade. Se realmente precisar mapear externamente a porta de mensageria confiável, use então -ExternalReliablePort conforme a documentação oficial e atualize o firewall de acordo.
Depois que o servidor rodar com sucesso pela primeira vez, abra o cliente de Satisfactory e entre em Server Manager pelo menu principal:
- Escolha adicionar um servidor e informe o IP público do VPS e a porta padrão
7777. - A primeira conexão pedirá para reivindicar o servidor; defina o nome do servidor e a senha de administrador.
- A senha de administrador deve ser aleatória e única; não reutilize a senha de SSH, e-mail ou Steam.
- Crie um novo jogo ou importe um save
.savexistente. - Nas configurações do servidor, confirme o intervalo de autosave, o salvamento ao desconectar e o carregamento automático da sessão.
- Se quiser um servidor privado, defina também uma senha de conexão para jogadores e compartilhe apenas por canais privados.
As configurações de administração do servidor são salvas em um local semelhante ao seguinte, onde PORT é substituído pela porta que a instância realmente usa:
/home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames/ServerSettings.PORT.sav
O diretório de saves do servidor Linux é:
/home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames/server
Ao importar um save antigo, pare o servidor primeiro e depois copie o arquivo .sav como o usuário satisfactory, para evitar que a propriedade de root impeça o jogo de lê-lo:
sudo systemctl stop satisfactory 2>/dev/null || true
sudo install -d -o satisfactory -g satisfactory \
/home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames/server
sudo cp /path/to/your-save.sav \
/home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames/server/
sudo chown satisfactory:satisfactory \
/home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames/server/your-save.sav
Substitua /path/to/your-save.sav pelo caminho real do arquivo. Depois de iniciar, escolha carregar esse save no Server Manager; não edite diretamente os binários .sav ou ServerSettings.PORT.sav.
Depois que a inicialização em primeiro plano, as portas e o claim estiverem confirmados como corretos, crie /etc/systemd/system/satisfactory.service:
[Unit]
Description=Satisfactory dedicated server
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
User=satisfactory
Group=satisfactory
Environment=HOME=/home/satisfactory
WorkingDirectory=/opt/satisfactory
ExecStartPre=/opt/steamcmd/steamcmd.sh +force_install_dir /opt/satisfactory +login anonymous +app_update 1690800 validate +quit
ExecStart=/opt/satisfactory/FactoryServer.sh -Port=7777 -ReliablePort=8888
Restart=on-failure
RestartSec=60
KillSignal=SIGINT
TimeoutStopSec=180
[Install]
WantedBy=multi-user.target
Esta configuração se baseia no guia da Wiki oficial para executar como serviço systemd e define explicitamente HOME para garantir que os saves fiquem no diretório esperado do usuário do serviço.
Recarregue o systemd e inicie:
sudo systemctl daemon-reload
sudo systemctl enable --now satisfactory
sudo systemctl status satisfactory --no-pager
sudo journalctl -u satisfactory -n 100 --no-pager
ExecStartPre executa o SteamCMD antes de cada inicialização do serviço, então reiniciar o serviço verifica atualizações primeiro. Isso é conveniente para manutenção, mas se o serviço travar repetidamente por causa de um erro, a verificação de atualizações também será executada novamente antes de cada reinício. Não altere RestartSec para alguns segundos e não use um loop rápido infinito para mascarar uma falha real.
Ver logs em tempo real:
sudo journalctl -u satisfactory -f
Os logs do próprio jogo geralmente ficam em:
/opt/satisfactory/FactoryGame/Saved/Logs
Se o systemd mostrar active (running) mas os jogadores ainda não conseguirem entrar, primeiro verifique nos logs se o carregamento do mundo foi concluído e depois confira se as três portas estão em escuta ao mesmo tempo. Não julgue que o mundo do jogo está conectável apenas pelo status do processo.
Não execute app_update diretamente enquanto o processo do servidor estiver em execução. O erro de atualização 0x606 listado na documentação oficial costuma ser causado por um FactoryServer em execução ocupando os arquivos que serão substituídos.
O processo seguro de atualização é:
- Salve manualmente no Server Manager ou no jogo, por exemplo como
before-update. - Avise os jogadores para saírem e aguarde o salvamento terminar.
- Pare o serviço.
- Execute a atualização do SteamCMD e valide.
- Reinicie e verifique os logs e a versão.
Os comandos são os seguintes:
sudo systemctl stop satisfactory
sudo -u satisfactory env HOME=/home/satisfactory \
/opt/steamcmd/steamcmd.sh \
+force_install_dir /opt/satisfactory \
+login anonymous \
+app_update 1690800 validate \
+quit
sudo systemctl start satisfactory
sudo journalctl -u satisfactory -n 100 --no-pager
Como a unit systemd deste artigo já inclui ExecStartPre, depois de executar o SteamCMD manualmente, systemctl start verificará mais uma vez, o que geralmente termina rápido. Você também pode, após salvar, executar diretamente sudo systemctl restart satisfactory e deixar o systemd atualizar automaticamente depois de parar o serviço.
Antes de uma atualização de versão principal, não dependa de apenas um backup local. Consulte primeiro as notas de patch oficiais e os problemas conhecidos da comunidade, mantenha uma cópia do save que permita reverter e depois agende uma janela de manutenção.
O diretório principal que precisa de backup não é o de instalação, mas Saved dentro do HOME do usuário do serviço:
sudo -u satisfactory find \
/home/satisfactory/.config/Epic/FactoryGame/Saved \
-maxdepth 3 -type f -printf '%TY-%Tm-%Td %TH:%TM %p\n' \
| tail -n 30
Antes da manutenção, salve no jogo primeiro, depois pare o servidor e crie um arquivo compactado com timestamp:
sudo systemctl stop satisfactory
backup_stamp=$(date +%Y%m%d-%H%M%S)
sudo tar \
-C /home/satisfactory/.config/Epic/FactoryGame \
-czf "/var/backups/satisfactory/satisfactory-${backup_stamp}.tar.gz" \
Saved
sudo systemctl start satisfactory
sudo ls -lh /var/backups/satisfactory
Verifique por amostragem se o arquivo compactado pode ser lido:
latest_backup=$(sudo find /var/backups/satisfactory \
-maxdepth 1 -type f -name 'satisfactory-*.tar.gz' \
-print | sort | tail -n 1)
sudo tar -tzf "$latest_backup" | head -n 30
Recomenda-se manter pelo menos "os últimos 7 backups diários e os últimos 4 backups semanais" e sincronizar cópias para um domínio de falha diferente do VPS. Para scripts de backup, armazenamento de objetos e simulações de restauração, consulte o guia de estratégia de backup de VPS.
A restauração substitui o Saved atual, então primeiro faça outro snapshot do estado atual:
sudo systemctl stop satisfactory
restore_stamp=$(date +%Y%m%d-%H%M%S)
sudo mv \
/home/satisfactory/.config/Epic/FactoryGame/Saved \
"/home/satisfactory/.config/Epic/FactoryGame/Saved.before-restore-${restore_stamp}"
sudo -u satisfactory tar \
-C /home/satisfactory/.config/Epic/FactoryGame \
-xzf /var/backups/satisfactory/satisfactory-YYYYMMDD-HHMMSS.tar.gz
sudo chown -R satisfactory:satisfactory \
/home/satisfactory/.config/Epic/FactoryGame/Saved
sudo systemctl start satisfactory
sudo journalctl -u satisfactory -n 100 --no-pager
Substitua o nome do arquivo pelo backup real que você quer restaurar. Depois de iniciar, peça ao administrador para entrar primeiro no Server Manager e confirmar a sessão, o horário do save e as configurações do servidor, e só então deixe os outros jogadores entrarem.
Verifique primeiro os logs completos, em vez de executar systemctl restart repetidamente:
sudo systemctl status satisfactory --no-pager -l
sudo journalctl -u satisfactory -b --no-pager
find /opt/satisfactory/FactoryGame/Saved/Logs \
-maxdepth 1 -type f -printf '%TY-%Tm-%Td %TH:%TM %p\n' \
| sort | tail
Confirme que o sistema é x86_64, que a memória não foi morta pelo OOM Killer, que a propriedade dos diretórios está correta, e verifique se o VPS usa um modelo de CPU kvm64 com problemas de compatibilidade:
uname -m
lscpu | grep 'Model name'
sudo journalctl -k | grep -i -E 'out of memory|killed process|oom'
sudo chown -R satisfactory:satisfactory \
/opt/satisfactory /home/satisfactory
Primeiro confirme a escuta local:
sudo ss -lntup | grep -E ':7777|:8888'
sudo ufw status numbered
curl -k https://127.0.0.1:7777
Depois verifique se as três regras do grupo de segurança na nuvem estão presentes. O erro mais comum é abrir apenas 7777/UDP e esquecer 7777/TCP ou 8888/TCP; outro erro comum é seguir tutoriais antigos e abrir apenas 15777/UDP e 15000/UDP.
Primeiro confirme que o serviço realmente parou:
sudo systemctl stop satisfactory
pgrep -af FactoryServer || echo 'server stopped'
sudo -u satisfactory /opt/steamcmd/steamcmd.sh \
+force_install_dir /opt/satisfactory \
+login anonymous \
+app_update 1690800 validate \
+quit
Se ainda for possível ver o processo FactoryServer, não execute kill -9 diretamente. Primeiro descubra se ele foi iniciado por outro terminal, script ou unit systemd duplicada, e envie SIGINT da forma correspondente para encerrá-lo normalmente.
Verifique se o arquivo está no diretório correto do servidor Linux, se a extensão é .sav e se o proprietário é satisfactory:
sudo -u satisfactory find \
/home/satisfactory/.config/Epic/FactoryGame/Saved/SaveGames/server \
-maxdepth 1 -type f -name '*.sav' -ls
Se o arquivo pertencer a root, corrija a propriedade, reinicie o serviço e depois escolha carregá-lo no Server Manager. Não sobrescreva o save ativo enquanto o servidor estiver em execução.
Registre dados antes de fazer upgrade do plano:
free -h
uptime
vmstat 1 10
pid=$(pgrep -n FactoryServer-Linux-Shipping || pgrep -n FactoryServer)
ps -p "$pid" -o pid,%cpu,%mem,rss,etime,cmd
Se uma única vCPU ficar próxima da carga máxima por muito tempo, priorize trocar para uma instância com maior desempenho de um único núcleo; se a memória disponível estiver muito baixa e houver swapping contínuo, adicione memória. Quando a espera de disco estiver alta, verifique o desempenho do NVMe e se as tarefas de backup se sobrepõem aos autosaves. Servidores de longo prazo podem integrar monitoramento de VPS com Prometheus e Grafana para observar tendências de CPU, memória, disco e rede.
uname -méx86_64, e a CPU não é um modelo antigokvm64com riscos de compatibilidade.- O SteamCMD usa o App ID do servidor dedicado
1690800, não o App ID do cliente do jogo. - O serviço roda com um usuário
satisfactorydedicado, não com root. 7777/TCP,7777/UDPe8888/TCPestão liberadas tanto no UFW quanto no grupo de segurança na nuvem.- O servidor foi reivindicado no Server Manager e uma senha de administrador única foi definida.
- O autosave, o salvamento ao desconectar e o carregamento automático da sessão estão configurados conforme a necessidade.
- O systemd consegue iniciar no boot,
KillSignal=SIGINT, e os logs não mostram um loop de travamentos persistente. - Antes de atualizar, você salva e para o serviço primeiro, e nunca executa o SteamCMD com o FactoryServer em execução.
- Um teste de leitura de backup foi concluído e pelo menos um backup foi copiado para fora do site.
- Você realmente entrou, saiu e reconectou a partir de um cliente externo, e confirmou que o progresso mais recente ainda existe.
Só depois de concluir essas verificações este VPS passa de "consegue iniciar" para "mantenível a longo prazo". Para um servidor de jogo como o de Satisfactory, cujos saves não param de crescer, uma CPU estável, as novas portas corretas, backups verificáveis e uma manutenção com ritmo importam muito mais do que fazer o programa rodar uma vez.