Montar um servidor de 7 Days to Die em VPS (2026): V3.1, SteamCMD, portas, backups e atualizações

Até agosto de 2026, a The Fun Pimps lançou a versão estável V3.1.0 Henpocalypse. O anúncio oficial também lembra especificamente: quando o servidor dedicado não consegue conectar, é preciso confirmar que o servidor selecionou Default Public Version, ou seja, a branch estável atual V3.1.0.

Portanto, um servidor novo não precisa adicionar latest_experimental nem parâmetros da antiga branch Alpha. O cliente e o servidor devem usar versões compatíveis; se os colegas ficarem na branch experimental enquanto o servidor usa a branch estável padrão, o resultado mais comum é incompatibilidade de versão ou impossibilidade de entrar.

A V3.1 ajustou opções de sandbox como densidade de inimigos e animais de dia e de noite e taxas de spawn, então códigos de presets antigos podem deixar de funcionar. Faça backup antes de atualizar um servidor existente e não teste diretamente no seu único save. Este artigo é pensado para um servidor novo; mundos existentes de V2.6/V3.0 devem primeiro ser verificados em uma cópia.

O FAQ oficial de suporte dá um ponto de partida mínimo de quatro núcleos a 2,8 GHz, 8 GB de memória e 20 GB de espaço disponível, e recomenda quatro núcleos a 3,2 GHz e 16 GB de memória. Ele também avisa que um mapa aleatório grande pode ocupar cerca de 15 GB por si só, e que quanto mais jogadores houver, maiores serão os requisitos de memória e largura de banda.

Abaixo estão recomendações de partida mais adequadas para comprar uma VPS; não são garantias de desempenho:

7 Days to Die é sensível ao desempenho de um único núcleo, à memória e à latência do disco. Não olhe só para o rótulo "8 núcleos"; nós baratos com sobrevenda grave costumam travar ao gerar mapas, carregar chunks novos ou durante a noite de horda. Antes de comprar, você pode ler primeiro Especificações de VPS para servidores de jogos e escolha de rota de rede.

Este artigo usa SteamCMD + systemd porque, quando surgem problemas de versão, portas ou saves, você consegue ver diretamente os arquivos e logs oficiais. Se a mesma máquina também rodar Minecraft, Rust ou Project Zomboid, você pode considerar então o Painel de servidores de jogos Pterodactyl.

A porta base padrão é 26900. As portas de entrada listadas atualmente no FAQ oficial de suporte são:

Portanto, as regras mínimas do firewall são 26900/tcp e 26900:26903/udp. Não abra todas as portas altas por conveniência, nem exponha o Web Dashboard ou o Telnet para toda a internet.

Se você alterar ServerPort, as portas UDP relacionadas também se deslocam junto com a porta base. Este artigo mantém 26900 para evitar que os números fiquem inconsistentes na configuração do servidor, no UFW e no grupo de segurança da nuvem.

Primeiro atualize o sistema e instale os componentes básicos:

sudo apt update
sudo apt upgrade -y
sudo apt install -y curl ca-certificates tar lib32gcc-s1 ufw

Crie uma conta de serviço que não possa fazer login diretamente com senha:

sudo adduser --system --group --home /home/sdtd --shell /bin/bash sdtd
sudo install -d -o sdtd -g sdtd /opt/steamcmd
sudo install -d -o sdtd -g sdtd /opt/7dtd-server
sudo install -d -o sdtd -g sdtd /srv/7dtd-data
sudo install -d -m 750 -o root -g sdtd /var/backups/7dtd

Não rode o jogo como root. Uma conta dedicada limita as permissões do serviço e também evita que as atualizações do SteamCMD gerem arquivos de propriedade do root, o que faz a próxima atualização ou salvamento falhar.

Troque para o usuário sdtd e baixe o SteamCMD oficial da Valve:

sudo -iu sdtd
cd /opt/steamcmd
curl -fsSL https://steamcdn-a.akamaihd.net/client/installer/steamcmd_linux.tar.gz \
  -o steamcmd_linux.tar.gz
tar -xzf steamcmd_linux.tar.gz
./steamcmd.sh +quit

Confirme que o ponto de entrada é executável:

test -x /opt/steamcmd/steamcmd.sh

O App ID da Steam do 7 Days to Die Dedicated Server é 294420. O login anônimo já basta para baixar:

/opt/steamcmd/steamcmd.sh \
  +force_install_dir /opt/7dtd-server \
  +login anonymous \
  +app_update 294420 validate \
  +quit

O comando não tem o parâmetro -beta, então ele obtém a branch estável padrão atual. Após a instalação, verifique os arquivos principais:

test -x /opt/7dtd-server/startserver.sh
test -f /opt/7dtd-server/serverconfig.xml
grep -n 'buildid' /opt/7dtd-server/steamapps/appmanifest_294420.acf
du -sh /opt/7dtd-server

Saia da conta de serviço:

exit

As atualizações do SteamCMD podem sobrescrever a configuração de exemplo no diretório de instalação. Primeiro copie o arquivo que acompanha a versão atual para o diretório de dados:

sudo -u sdtd cp /opt/7dtd-server/serverconfig.xml \
  /srv/7dtd-data/serverconfig.xml
sudo -u sdtd cp /srv/7dtd-data/serverconfig.xml \
  /srv/7dtd-data/serverconfig.xml.initial
sudo -u sdtd nano /srv/7dtd-data/serverconfig.xml

Modifique apenas as propriedades que já existem no arquivo atual; não sobrescreva tudo com um tutorial antigo. No mínimo, verifique estes itens:

<property name="ServerName" value="My 7 Days to Die Server"/>
<property name="ServerDescription" value="Private V3.1 survival server"/>
<property name="ServerWebsiteURL" value=""/>
<property name="ServerPassword" value="REPLACE_WITH_PLAYER_PASSWORD"/>
<property name="ServerLoginConfirmationText" value=""/>
<property name="Region" value="Asia"/>
<property name="Language" value="Chinese"/>
<property name="ServerPort" value="26900"/>
<property name="ServerVisibility" value="2"/>
<property name="ServerMaxPlayerCount" value="8"/>
<property name="ServerReservedSlots" value="0"/>
<property name="ServerAdminSlots" value="1"/>
<property name="EACEnabled" value="true"/>
<property name="WebDashboardEnabled" value="true"/>
<property name="WebDashboardPort" value="8080"/>
<property name="TelnetEnabled" value="false"/>

Gere uma senha de jogador dedicada:

openssl rand -base64 24

Substitua o resultado em ServerPassword. É a senha pública para entrar no servidor, não uma senha da Steam, e não deve ser reutilizada com chaves SSH, contas de painel ou senhas de administrador.

O arquivo de configuração também tem opções de protocolo de rede, multiplataforma, perfis de jogador e sandbox. Mantenha por enquanto os padrões atuais da V3.1 e altere depois que o servidor vanilla conseguir ser acessado de forma estável. Em especial, para ServerDisabledNetworkProtocols, não copie um valor de um tutorial antigo para sobrescrever a configuração atual.

Para a primeira implantação, recomenda-se usar o mundo oficial Navezgane:

<property name="GameWorld" value="Navezgane"/>
<property name="GameName" value="MyV31World"/>
<property name="GameDifficulty" value="2"/>
<property name="DayNightLength" value="60"/>
<property name="DayLightLength" value="18"/>

Assim você verifica primeiro a versão, as portas, o EAC e o login dos jogadores, separando problemas de rede dos problemas de geração de mapa aleatório.

Depois de confirmar que o Navezgane funciona, troque para um mapa aleatório em uma janela de manutenção. As propriedades de mundo aleatório no arquivo de configuração da V3.1 devem seguir o exemplo atual; a abordagem comum é definir o tipo de mundo aleatório, uma seed única e um tamanho de 6144. Durante a geração, o uso de CPU, memória e disco aumenta bastante, então não faça isso com jogadores online.

GameName determina o identificador do save. Não o altere de ânimo leve depois que o servidor entrar em produção, caso contrário o servidor pode parecer que "perdeu o save" quando na verdade apenas iniciou outro diretório de jogo.

Rode primeiro em primeiro plano para ver diretamente a geração do mundo, o EAC, as portas e os erros de configuração:

sudo -u sdtd /opt/7dtd-server/startserver.sh \
  -configfile=/srv/7dtd-data/serverconfig.xml \
  -UserDataFolder=/srv/7dtd-data

A primeira inicialização pode levar vários minutos. Não presuma que o servidor está no ar só porque viu um processo Java/Unity; espere o log mostrar que o mundo do jogo terminou de carregar e está escutando na porta do servidor.

Crie um usuário do Web Dashboard no console:

createwebuser

Siga as instruções para criar uma conta de administrador dedicada e uma senha forte. Depois, digite no console:

saveworld
shutdown

Espere o mundo salvar e sair normalmente. Não feche o SSH diretamente nem use kill -9. Verifique o diretório de dados:

sudo -u sdtd find /srv/7dtd-data -maxdepth 3 -type f | sort | head -n 120
sudo du -sh /srv/7dtd-data

Crie a unidade de serviço:

sudo nano /etc/systemd/system/7dtd.service

Escreva:

[Unit]
Description=7 Days to Die Dedicated Server
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=sdtd
Group=sdtd
WorkingDirectory=/opt/7dtd-server
ExecStart=/opt/7dtd-server/startserver.sh -configfile=/srv/7dtd-data/serverconfig.xml -UserDataFolder=/srv/7dtd-data
Restart=on-failure
RestartSec=20
KillSignal=SIGINT
TimeoutStopSec=300
LimitNOFILE=65535

[Install]
WantedBy=multi-user.target

Carregue e inicie:

sudo systemctl daemon-reload
sudo systemctl enable --now 7dtd
sudo systemctl status 7dtd --no-pager
sudo journalctl -u 7dtd -n 250 --no-pager

LimitNOFILE=65535 serve para evitar atingir o limite baixo de arquivos abertos do Linux com mundos grandes ou muitos jogadores. O FAQ oficial de suporte também documentou especificamente o problema de nofile=1024 que faz o serviço não iniciar.

Depois de parar o serviço, confirme que o processo terminou antes de fazer o backup:

sudo systemctl stop 7dtd
sudo systemctl status 7dtd --no-pager

Se após 300 segundos ele ainda não tiver terminado, verifique primeiro os logs e o espaço em disco; não mate à força imediatamente. O encerramento forçado pode corromper chunks ou dados de jogador que estão sendo gravados.

Mantenha a sessão SSH atual aberta, libere primeiro o SSH e depois adicione as portas do jogo:

sudo ufw allow OpenSSH
sudo ufw allow 26900/tcp
sudo ufw allow 26900:26903/udp
sudo ufw status numbered
sudo ufw enable

O grupo de segurança do provedor de nuvem também precisa adicionar as mesmas regras. Verifique a escuta:

sudo ss -lntup | grep -E ':26900|:26901|:26902|:26903'

Não adicione regras públicas para 8080/tcp nem 8081/tcp. Acesse o Web Dashboard por túnel SSH e mantenha o Telnet fechado.

No seu próprio computador, execute:

ssh -L 8080:127.0.0.1:8080 [email protected]

Mantenha a sessão SSH e depois abra:

http://127.0.0.1:8080

Faça login com o usuário web criado na primeira inicialização em primeiro plano. Como o UFW e o grupo de segurança da nuvem não abrem a 8080, scanners públicos não conseguem acessar diretamente essa entrada de administração.

Se a porta local 8080 já estiver em uso, você pode mudar para a local 18080:

ssh -L 18080:127.0.0.1:8080 [email protected]

Depois acesse http://127.0.0.1:18080.

Não trate a senha pública para entrar no servidor como um sistema de permissões. Os administradores devem usar a própria identidade Steam/EOS e dar permissões apenas a quem realmente precisa.

Adicione um administrador no console do servidor ou no Web Dashboard protegido pelo túnel SSH:

admin add STEAM64_ID 0

Adicione à lista de permissões:

whitelist add STEAM64_ID

Veja a lista atual:

admin list
whitelist list
ban list

O formato específico de identidade e a ajuda dos comandos podem mudar conforme a versão e a plataforma de rede; antes de executar, digite primeiro help admin e help whitelist no console atual da V3.1. Não copie diretamente serveradmin.xml de um servidor desconhecido; ele pode conter identidades erradas, IDs de plataforma antigos ou contas de alto privilégio desnecessárias.

Primeiro faça um jogador conectar diretamente usando o IP público:

IP: 203.0.113.20
Port: 26900
Password: serverconfig.xml 中的 ServerPassword

Substitua o IP de exemplo pelo endereço real da VPS. Quando a conexão direta funcionar, verifique a lista de servidores e a entrada multiplataforma, assim fica mais fácil distinguir problemas de atualização da lista, de EOS/Steam e de rede básica.

Um domínio pode criar um registro A normal apontando para o IPv4 da VPS, mas o proxy HTTP normal da Cloudflare (nuvem laranja) não consegue encaminhar as portas de jogo do 7 Days to Die e deve ser configurado como DNS only.

Este artigo usa explicitamente:

-UserDataFolder=/srv/7dtd-data

Portanto, mundos, jogadores, logs e mapas gerados fora da configuração ficam concentrados em /srv/7dtd-data. Os subdiretórios podem mudar conforme a versão e o tipo de mundo; não adivinhe os caminhos só pelos tutoriais, confirme primeiro com os arquivos reais:

sudo -u sdtd find /srv/7dtd-data -maxdepth 4 -type f | sort | head -n 200
sudo du -h -d 3 /srv/7dtd-data | sort -h | tail -n 40

/opt/7dtd-server são arquivos de programa que podem ser reinstalados pelo SteamCMD, enquanto /srv/7dtd-data são os mundos, jogadores, permissões, logs e mapas gerados que não podem ser perdidos.

O mais seguro é parar o servidor em uma janela de manutenção e empacotar todo o diretório de dados:

sudo systemctl stop 7dtd
sudo tar -C /srv -czf \
  "/var/backups/7dtd/7dtd-data-$(date -u +%Y%m%dT%H%M%SZ).tar.gz" \
  7dtd-data
sudo systemctl start 7dtd
sudo systemctl is-active 7dtd

Verifique o arquivo:

sudo ls -lh /var/backups/7dtd
sudo tar -tzf /var/backups/7dtd/7dtd-data-YYYYMMDDTHHMMSSZ.tar.gz | head -n 120

Substitua o nome de arquivo de exemplo pelo arquivo real. Mantenha pelo menos uma cópia em outra máquina ou em armazenamento de objetos, e defina um período de retenção; guardar os backups apenas no mesmo disco da VPS significa que eles se perdem juntos se a máquina falhar. Para uma solução completa, consulte Backups e simulações de restauração em VPS.

Pare o servidor antes de restaurar e mantenha o diretório atual como reversão temporária:

sudo systemctl stop 7dtd
sudo tar -tzf /var/backups/7dtd/7dtd-data-YYYYMMDDTHHMMSSZ.tar.gz | head -n 120
sudo mv /srv/7dtd-data \
  "/srv/7dtd-data.before-restore-$(date -u +%Y%m%dT%H%M%SZ)"
sudo tar -C /srv -xzf \
  /var/backups/7dtd/7dtd-data-YYYYMMDDTHHMMSSZ.tar.gz
sudo chown -R sdtd:sdtd /srv/7dtd-data
sudo systemctl start 7dtd

Verifique após restaurar:

sudo systemctl status 7dtd --no-pager
sudo journalctl -u 7dtd -n 300 --no-pager
sudo du -sh /srv/7dtd-data

Faça um jogador de teste entrar e verifique personagens, inventário, bases, reivindicações de terreno, missões, exploração do mapa e permissões de administrador. Não apague 7dtd-data.before-restore-* antes de concluir a aceitação; ele é o ponto de reversão desta simulação.

Pare o servidor e faça backup antes de atualizar, depois atualize apenas a branch estável padrão. Crie o script:

sudo nano /usr/local/sbin/update-7dtd-server

Escreva:

#!/usr/bin/env bash
set -euo pipefail

backup_dir=/var/backups/7dtd
stamp=$(date -u +%Y%m%dT%H%M%SZ)
was_active=0

install -d -m 750 -o root -g sdtd "$backup_dir"

if systemctl is-active --quiet 7dtd; then
  was_active=1
  systemctl stop 7dtd
fi

restart_service() {
  if [ "$was_active" -eq 1 ]; then
    systemctl start 7dtd
  fi
}
trap restart_service EXIT

tar -C /srv -czf \
  "$backup_dir/7dtd-before-update-$stamp.tar.gz" \
  7dtd-data

sudo -u sdtd /opt/steamcmd/steamcmd.sh \
  +force_install_dir /opt/7dtd-server \
  +login anonymous \
  +app_update 294420 \
  +quit

test -x /opt/7dtd-server/startserver.sh
test -f /srv/7dtd-data/serverconfig.xml

Defina as permissões e execute manualmente:

sudo chown root:root /usr/local/sbin/update-7dtd-server
sudo chmod 750 /usr/local/sbin/update-7dtd-server
sudo /usr/local/sbin/update-7dtd-server
sudo systemctl is-active 7dtd
sudo journalctl -u 7dtd -n 250 --no-pager

O script não tem -beta latest_experimental, então não muda ativamente para a branch experimental. Após uma atualização bem-sucedida, confirme nos logs a versão, o carregamento do mundo e a entrada de jogadores; não encerre a manutenção só porque o SteamCMD retornou sucesso.

Um servidor privado vanilla pode verificar atualizações diariamente em uma janela fixa; servidores com mods e servidores públicos são mais adequados para manutenção manual, para evitar que o servidor atualize primeiro enquanto os clientes ou os mods ainda não acompanharam.

Crie um serviço oneshot:

sudo nano /etc/systemd/system/7dtd-update.service

[Unit]
Description=Update 7 Days to Die Dedicated Server

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/update-7dtd-server

Crie um timer:

sudo nano /etc/systemd/system/7dtd-update.timer

[Unit]
Description=7 Days to Die daily maintenance window

[Timer]
OnCalendar=*-*-* 05:40:00
RandomizedDelaySec=10m
Persistent=true

[Install]
WantedBy=timers.target

Carregue e veja:

sudo systemctl daemon-reload
sudo systemctl enable --now 7dtd-update.timer
systemctl list-timers 7dtd-update.timer

Quando sair uma grande versão estável, o mundo estiver sendo convertido ou a compatibilidade de mods não estiver clara, desative primeiro o timer:

sudo systemctl disable --now 7dtd-update.timer

O anúncio oficial da V3.1 informa que saves antigos geralmente podem ser atualizados, mas também recomenda fazer backup; as novas opções de densidade dia/noite e de spawn também podem invalidar códigos de presets de sandbox antigos. O processo seguro é:

1. Pare o serviço antigo e faça backup de todo o diretório de dados do usuário.
2. Anote o build do servidor antigo, a lista de mods e serverconfig.xml.
3. Copie o save para um diretório separado; não mexa no único mundo de produção.
4. Desative primeiro os mods de terceiros e carregue a cópia com a versão estável atual.
5. Verifique presets de sandbox personalizados, jogadores, bases, chunks e missões.
6. Só depois que a cópia passar na aceitação, agende a troca em produção.

Não "conserte" uma incompatibilidade de versão apagando o save. Se as branches do servidor e do cliente forem diferentes, unifique primeiro as versões; corrupção de chunks, presets inválidos e conflitos de mods precisam de logs e backups para diagnosticar.

Para parada, arquivamento completo de dados e verificações de restauração em servidores de mundo aberto semelhantes, você também pode consultar o Processo de backup do servidor dedicado de Project Zomboid para criar um hábito fixo de manutenção.

Primeiro faça o servidor vanilla V3.1 rodar de forma estável e depois adicione mods. Adicione apenas alguns por vez e anote a origem, a versão e a configuração. A página de um mod dizer "compatível com V3" não significa que ele já seja compatível com a V3.1.

EACEnabled=true é adequado para servidores vanilla e servidores que precisam de anti-cheat. Alguns mods exigem desativar o EAC, mas isso muda o limite de segurança. Altere apenas quando a documentação do mod exigir explicitamente e todos os jogadores entenderem o risco, e não trate "desativar o EAC" como uma correção universal para qualquer erro de inicialização.

Antes de atualizar mods, conclua:

• Backup do mundo e dos dados dos jogadores.
• Salve os arquivos de mod atuais e a lista de versões.
• Teste a inicialização e a entrada em um mundo cópia.
• Verifique nos logs erros de XML, Harmony, EAC e rede.
• Mantenha a versão anterior dos arquivos para reverter rapidamente.

Registre dados durante a geração de mapa aleatório, a noite de horda e a exploração dispersa de vários jogadores:

free -h
df -h /opt/7dtd-server /srv/7dtd-data /var/backups/7dtd
uptime
ps -eo pid,%cpu,%mem,rss,etime,cmd | grep '[7]DaysToDieServer'
sudo journalctl -u 7dtd --since "30 minutes ago" --no-pager

Fenômenos comuns:

• Memória e CPU altas por muito tempo durante a geração do mapa: espere primeiro a geração terminar, não reinicie com frequência.
• Um único núcleo no máximo na noite de horda: reduza o número de jogadores, a densidade de inimigos ou troque para uma VPS com melhor desempenho de um único núcleo.
• Travamentos quando os jogadores exploram separados: verifique a latência do disco, a memória e o carregamento de chunks novos.
• Saves cada vez maiores: deixe espaço para backups locais, sincronização externa e extração de restauração.
• Latência perceptível no pico da noite: compare a perda de pacotes UDP e as rotas do data center, não apenas adicione memória.

• O SteamCMD instalou o App ID 294420, sem usar parâmetros da branch experimental.
• Cliente e servidor estão na branch estável pública padrão atual V3.1.
• O serviço usa um usuário sdtd dedicado e não roda como root.
• A configuração vem do serverconfig.xml incluído na versão atual, sem sobrescrever tudo com um modelo antigo.
• systemctl is-active 7dtd retorna active.
• LimitNOFILE=65535 está em vigor no systemd.
• 26900 TCP e 26900–26903 UDP estão abertos no UFW e no grupo de segurança.
• O Web Dashboard é acessado apenas por túnel SSH, e o Telnet não está exposto à internet.
• Os jogadores conseguem entrar por IP público:26900, e problemas da lista de servidores são investigados separadamente.
• Os administradores usam identidades pessoais, e a conta de maior privilégio não é compartilhada.
• /srv/7dtd-data foi totalmente copiado para outra máquina ou armazenamento de objetos.
• Foi feita uma simulação de restauração e verificados personagens, bases, chunks e permissões.
• Antes de atualizações de grande versão e de mods, o servidor é parado, o backup é feito e uma cópia de reversão é mantida.

• The Fun Pimps: anúncio da versão estável V3.1.0 Henpocalypse
• The Fun Pimps: FAQ de suporte e portas do servidor dedicado
• Valve Developer Community: 7 Days to Die Dedicated Server
• Valve Developer Community: SteamCMD

Onde um servidor de 7 Days to Die realmente dá errado não é no SteamCMD, mas na branch de versão, nas portas, nos mapas aleatórios e nos backups. Primeiro faça a V3.1, a 26900 TCP e a 26900–26903 UDP funcionarem com o mundo vanilla Navezgane, e depois adicione mapas aleatórios e mods; a solução de problemas será muito mais simples.

Para operação a longo prazo, trate /srv/7dtd-data como o ativo principal: pare o servidor normalmente antes de atualizar, faça backup completo e restaure de verdade uma vez. Assim, mesmo que você encontre mudanças em presets de sandbox, conflitos de mods ou corrupção de chunks, poderá voltar a um mundo confirmado como funcional, em vez de arriscar no seu único save.