PROJETO NOVO JOGO ▸ SERVIDOR & INFRAESTRUTURA

A sala de máquinas.

O plano completo da infraestrutura na AWS: o servidor de jogo em São Paulo e o sistema de download e atualização automática.

SEÇÃO 01

Visão geral

Três peças, cada uma no lugar mais barato e seguro possível. O princípio herdado da pesquisa: IP público no servidor de jogo elimina NAT; nada de listagem anônima de arquivos elimina bots.

10 CLIENTES WINDOWSlauncher próprio: verifica manifesto, baixa só o que mudou, aplica e abre o jogo
HTTPS + token
MÁQUINA ATUAL (eu-west-1)já existe e já paga: emite URLs assinadas de download, hospeda o painel liga/desliga e estas páginas
URL assinada 15 min
S3 — BUILDS (eu-west-1)bucket 100% privado com os arquivos do jogo; ninguém acessa sem URL assinada
GAME.LIZTEM.COMEC2 m6a.large em sa-east-1 (São Paulo) · servidor dedicado Linux · 1 porta UDP e mais nada · liga por botão, desliga sozinho
local
SQLITE + WATCHDOGsaves no servidor, gravação atômica; 0 jogadores por 30 min = desliga sozinho
noturno
S3 — BACKUPSsnapshot diário do save, versionado, 30 dias de retenção
SEÇÃO 02

Custos estimados

Cenário: ~2 noites de jogo por semana, ~3 h cada (≈ 25 h/mês de servidor ligado). Preços de agosto de 2026, com folga de arredondamento.

ITEMDETALHEUS$/MÊS
Servidor de jogom6a.large sa-east-1, US$ 0,1377/h × ~25 h (desligado não cobra computação)~3,50
Disco do servidorEBS gp3 30 GB (cobra mesmo desligado)~4,50
IP fixoIPv4 público (game.liztem.com aponta pra ele)~3,60
Backups de saveS3 versionado, uns poucos GB<0,50
Distribuição — armazenamentoS3 eu-west-1, build de ~5 GB + versões antigas~0,50
Distribuição — tráfegopatches mensais ~5 GB total pros 10 (US$ 0,09/GB)~0,50
Alarmes e orçamentosAWS Budgets + CloudWatch + SNS~0
Total típicojogo ativo, 8-9 sessões/mês≈ 13
  • Primeiro mês tem um extra único: download inicial completo pros 10 amigos (~5 GB × 10 = 50 GB ≈ US$ 4,50 de tráfego).
  • Se o grupo viciar e pedir servidor 24/7: vira ~US$ 62/mês com instância reservada de 1 ano — decisão pra depois, se acontecer.
  • Teto de gasto vigiado por alarme (Seção 03): surpresa de fatura é tratada como incidente, não como destino.
SEÇÃO 03

Segurança

A REGRA ZERONenhum arquivo do projeto é servido anonimamente, nunca. Sem file_server browse, sem bucket público, sem URL adivinhável. Bot que chegar encontra 403 e vai embora.
SUPERFÍCIE MÍNIMA O servidor de jogo só fala UDP

Security Group com exatamente 1 porta UDP aberta (a do jogo). Zero HTTP, zero SSH exposto — administração via SSM Session Manager, o mesmo esquema seguro desta máquina. Não existe porta pra bot escanear.

DOWNLOADS URL assinada, curta e revogável

O launcher se apresenta com um token individual por amigo; recebe URLs S3 assinadas com validade de 15 minutos. Token vazou? Revoga-se um amigo, não o sistema. Bucket tem Block Public Access ligado — acesso anônimo é impossível por construção.

DINHEIRO VIGIADO Alarmes antes da surpresa

AWS Budgets com avisos em €20, €35 e €50 por e-mail; alarme de tráfego de saída no servidor (>10 GB/dia = notifica E desliga a instância sozinho); o skill /aws-bill continua de plantão pra conferência manual.

DESLIGA SOZINHO Watchdog de ociosidade

0 jogadores por 30 minutos → o servidor se desliga. Timer de segurança absoluto: 8 h ligado direto → desliga com aviso no Discord. Esquecer ligado deixa de ser um risco financeiro.

MENOR PRIVILÉGIO IAM cirúrgico

O servidor de jogo só pode escrever no prefixo de backup do S3 — nada mais. O botão liga/desliga só pode dar start/stop naquela instância específica. Nenhuma credencial de longo prazo em disco.

RECUPERAÇÃO Backup com ensaio

Save versionado no S3 (30 dias) + snapshot semanal do disco. E um ensaio de restauração de verdade antes da primeira temporada — backup que nunca foi restaurado é loteria.

SEÇÃO 04

O servidor de jogo

  • Instância: m6a.large (2 vCPU dedicadas AMD, 8 GiB) em sa-east-1 — o veredito da contra-prova: família burstable (t3) estrangularia o tick na luta de chefe. Maioria brasileira joga com 10–60 ms; Willy absorve ~200 ms de Barcelona.
  • Sistema: Ubuntu Server LTS + systemd rodando o binário Linux headless da Unreal (Servidor.service, restart automático em queda).
  • Liga: botão autenticado num painel em gamepanel.liztem.com (hospedado nesta máquina, mesma basic_auth do brain) e/ou comando no Discord. ~90 s até aceitar conexões.
  • Desliga: sozinho — watchdog de 0 jogadores/30 min, teto absoluto de 8 h, e botão manual no painel.
  • Saves: SQLite em WAL no próprio servidor; recompensa de expedição grava atomicamente na extração; snapshot noturno pro S3 (e na hora do desligamento).
  • DNS: game.liztem.com → IP fixo da instância. Registro criado uma vez no GoDaddy (único passo manual do Willy em toda a infra).
  • Enquanto o jogo não existe: a Fase 2 sobe com um servidor de eco UDP de teste — a infra fica pronta e ensaiada antes da primeira build real.
SEÇÃO 05

Download e atualização automática — casa própria

Sem itch.io, por decisão. O desenho abaixo entrega a mesma experiência (instala uma vez, atualiza sozinho, só baixa o que mudou) com as peças que já temos.

Como funciona

  • O launcher (um instalador Windows pequeno, feito por nós na fase de build): na abertura, pergunta ao servidor de manifesto "qual a versão atual?", compara os hashes SHA-256 arquivo a arquivo e baixa só os arquivos que mudaram — patch típico de algumas centenas de MB, não a build inteira.
  • O manifesto vive nesta máquina (endpoint autenticado): responde apenas a tokens válidos e devolve URLs S3 assinadas de 15 minutos por arquivo. É a peça que torna o sistema imune a bot: não existe URL fixa pra descobrir.
  • Publicar versão nova (meu trabalho, 1 comando): script empacota a build, calcula hashes, sobe pro S3 e atualiza o manifesto. Os amigos recebem a atualização na próxima abertura do launcher.
  • Token por amigo: 10 tokens individuais distribuídos uma vez (Zap). Revogável um a um. Sem conta, sem senha pra esquecer — o launcher guarda o token.
  • Rollback: as 3 últimas versões ficam no S3 — voltar é apontar o manifesto pra trás.
POR QUE NÃO SERVIR DIRETO DESTA MÁQUINADaria — Caddy com basic_auth, como o upload.trizus.com. Mas os arquivos grandes sairiam pelo tráfego desta instância, exatamente a classe de custo do incidente. No S3 com URL assinada, o tráfego pesado sai de um lugar projetado pra isso, com o alarme de orçamento por cima e zero chance de acesso anônimo. Esta máquina só assina URLs — trabalho de miligramas.
SEÇÃO 06

Guia de execução — por fases

Cada fase é independente, reversível e termina com um teste. Legenda: EU EXECUTO WILLY FAZ

F0Rede de proteção primeiro30 min · pode rodar HOJE, antes de qualquer servidor

A lição do incidente: alarme vem ANTES da infraestrutura.

  1. AWS Budgets: orçamento mensal com avisos em €20 / €35 / €50 → e-mail. EU EXECUTO
  2. Billing alerts habilitados + alarme CloudWatch de estimativa de fatura. EU EXECUTO
  3. Confirmar e-mail de alerta (chega um SNS de confirmação pra clicar). WILLY FAZ
F1O servidor nasce~1 h
  1. Security Group "jogo": 1 porta UDP liberada, nada mais. EU EXECUTO
  2. Lançar m6a.large em sa-east-1 (Ubuntu LTS, gp3 30 GB, sem par de chaves — acesso só por SSM). EU EXECUTO
  3. IP fixo alocado e associado. EU EXECUTO
  4. Criar registro A game.liztem.com → IP fixo no painel do GoDaddy (te passo o IP e o passo a passo com print). WILLY FAZ
  5. IAM: papel do servidor só-backup; papel do painel só-liga/desliga. EU EXECUTO
  6. Teste: ping no DNS, SSM funcionando, porta UDP respondendo eco. EU EXECUTO
F2O servidor aprende a se cuidar~1 h
  1. systemd do servidor de jogo (por ora, eco UDP de teste) com restart automático. EU EXECUTO
  2. Watchdog: 0 jogadores/30 min → desliga; teto de 8 h → desliga e avisa. EU EXECUTO
  3. Backup: bucket S3 versionado + snapshot do save no desligamento e à 1h da manhã; snapshot semanal do disco. EU EXECUTO
  4. Alarme de tráfego: NetworkOut > 10 GB/dia → notifica e desliga. EU EXECUTO
  5. Teste: ensaio de restauração do save a partir do S3. EU EXECUTO
F3O botão de ligar~1 h
  1. Painel em gamepanel.liztem.com: estado do servidor, botão ligar/desligar, jogadores online — atrás de basic_auth (mesmas credenciais do brain). EU EXECUTO
  2. Opcional: comando/webhook no Discord do grupo ("!liga"). WILLY FAZ a parte de criar o webhook no Discord; o resto é meu.
  3. Teste: ciclo completo ligar → jogar (eco) → sair → desligamento automático. EU EXECUTO
F4A loja da casa (download e updates)~2 h + launcher na fase de build
  1. Bucket S3 privado de builds (eu-west-1, Block Public Access, versionado). EU EXECUTO
  2. Serviço de manifesto nesta máquina: valida token, assina URLs de 15 min. EU EXECUTO
  3. Script de publicação: empacota build → hashes → S3 → manifesto. EU EXECUTO
  4. 10 tokens gerados; distribuição no Zap. WILLY FAZ
  5. Launcher Windows (instala/atualiza/abre): entra no escopo da fase de build do jogo — o desenho já está pronto. EU EXECUTO
STATUSA F0 foi executada em 02/08 (alarmes ativos em US$ 20/35/40/50) e tudo que não depende de novas permissões está pronto. O estado real, tarefa por tarefa — incluindo as suas — vive em gameserver.liztem.com/tasks.
SEÇÃO 07

Runbook — a operação no dia a dia

SITUAÇÃOO QUE ACONTECE
Noite de jogoAlguém aperta o botão no painel (ou !liga no Discord) → 90 s → todo mundo conecta em game.liztem.com. No fim, ninguém faz nada: 30 min vazios e o servidor se desliga, salvando e enviando backup.
Update do jogoEu publico a versão; o launcher de cada um baixa só o que mudou na próxima abertura. Ninguém reinstala nada.
Amigo novo / token vazadoGero token novo em 1 comando; o antigo morre na hora. Willy manda no Zap.
Save corrompido / desastreRestauração do S3: qualquer noite dos últimos 30 dias, ensaio já feito na F2.
Alarme de €20 chegouWilly me chama, eu audito na hora (o /aws-bill já existe). Alarme de tráfego anômalo nem espera: desliga sozinho e avisa.
Grupo virou vício 24/7Migramos pra instância reservada (~US$ 62/mês) com um comando. Decisão de bom problema.