Construir uma plataforma de servidores de jogos parece simples até você precisar operar tudo.

Rede.
Hardware.
Virtualização.
Orquestração.
Provisionamento.
Isolamento.

Este post documenta como a infraestrutura do ceu.gg foi construída e quais decisões técnicas sustentam a plataforma hoje.

Infraestrutura do ceu.gg

O ceu.gg nasceu como um projeto técnico.

O objetivo não era apenas oferecer servidores gratuitos, mas construir uma engine própria de gerenciamento, com controle total da stack, do hardware ao painel.

A decisão central foi clara:

Infraestrutura majoritariamente própria
Engine de orquestração própria
Operação controlada
Arquitetura sustentável para uma equipe enxuta

Contexto e motivação técnica

A necessidade inicial não foi "criar um concorrente".

Foi resolver dois problemas:

Gerenciar servidores bare-metal e VMs de forma organizada
Ter um projeto real que exigisse aplicar redes, virtualização e containers

Historicamente, operar servidores diretamente em Linux puro ou VMs isoladas vira caos com crescimento.

O ceu.gg surgiu como uma resposta arquitetural a isso.

Requisitos inegociáveis

Desde o início, três pontos eram obrigatórios:

Engine 100% própria
Alto nível de personalização (versões, mods, plugins)
Modelo gratuito

Não era aceitável depender de painéis prontos ou engines fechadas.

Restrições reais

O projeto começou com limitações claras:

Hardware no Brasil é caro
Link é caro
Tempo é limitado
Equipe extremamente enxuta

Essas restrições moldaram todas as decisões arquiteturais.

Simplicidade deixou de ser estética e virou requisito técnico.

Decisão: infraestrutura própria

A plataforma roda em datacenter próprio.

Stack principal:

Proxmox para virtualização
Mikrotik para roteamento
Kubernetes para orquestração
MinIO como storage S3
Backend e painel desenvolvidos do zero

Hoje o controle é completo sobre:

Hardware
Rede
Virtualização
Cluster
Deploy
Backend/API
Frontend

O trade-off é claro:

Maior complexidade operacional
Alto investimento inicial em hardware
Responsabilidade total por incidentes

Mas o ganho é domínio técnico completo.

Arquitetura em camadas

A infraestrutura é dividida em camadas bem definidas.

Infraestrutura ceu.gg

1. Camada física (Datacenter)

Servidores físicos dedicados
Storage com disco dedicado para cold storage
Segmentação de rede

2. Camada de virtualização

VMs são usadas para:

Isolar componentes críticos
Minimizar impacto de manutenção
Separar control-plane e workloads

A virtualização reduz o impacto de falhas, evitando que um problema afete toda a infraestrutura.

3. Cluster Kubernetes

O cluster executa:

Backend principal
API
Watchdog
Componentes auxiliares
Servidores de jogos em containers

O Kubernetes trouxe:

Padronização de deploy
Restart automático
Resiliência básica
Limites de recursos por pod

Isso elimina grande parte do gerenciamento manual.

Fluxo end-to-end do usuário

Usuário cria servidor no painel
Backend valida regras e limites
Engine agenda provisionamento
Pod é criado no cluster
Watchdog monitora atividade
Sem usuários conectados → agendamento de desligamento
Dados são movidos para cold storage

O ciclo é controlado pela engine própria.

Scheduling atual

Hoje o scheduling é simples:

Alocação baseada em disponibilidade
Distribuição ainda sem estratégia regional

É um ponto claro de evolução.

Mas a simplicidade reduz risco inicial.

Performance: gargalos reais

Até agora, o maior risco identificado é rede.

Minecraft tem forte dependência de:

CPU single-thread
I/O de disco
Latência de rede

Com baixo número simultâneo de servidores, ainda não houve gargalos críticos.

Mas o monitoramento já indica que rede e memória tendem a ser os primeiros limitadores quando a plataforma ganhar escala.

Otimizações aplicadas

Algumas decisões técnicas para reduzir overhead:

Cache de imagens Docker
Templates pré-configurados
Cold storage para servidores inativos
Limites de CPU/memória por servidor

Objetivo: reduzir tempo de provisionamento e evitar desperdício.

Segurança em um serviço gratuito

Serviço gratuito atrai abuso.

Principais vetores mitigados:

Criação massiva de servidores
Execução de código arbitrário
Upload de arquivos maliciosos

Medidas aplicadas:

Proibição de upload executável
Controle via painel
Integração com CurseForge e Modrinth
Blacklist planejada para recursos problemáticos
Isolamento por container com limites de recursos

Sem acesso direto ao filesystem host.

Sem execução arbitrária.

Confiabilidade e incidentes

Dois incidentes relevantes já ocorreram:

Detach inesperado de HD usado como cold storage
Perda de acesso IPv4 por praticamente um dia inteiro

Ambos reforçaram:

Necessidade de redundância
Melhor segmentação de acesso
Procedimentos de recuperação

Operar infraestrutura própria ensina rápido.

Observabilidade

A stack inclui:

Prometheus
Grafana

O monitoramento cobre:

Uso de CPU (cluster e workloads)
Memória (nós e pods)
Pods ativos
Estado do cluster
API Gateway (latência, erros, throughput)
Servidores de jogos (uso de recursos e disponibilidade)

Isso permite enxergar:

Saturação de recursos
Picos de uso
Comportamentos anormais
Tendências de crescimento

Dashboard Grafana - ceu.gg

Sem métricas, não existe tomada de decisão técnica madura.

Produto e experiência

O foco sempre foi:

Fluxos simples
Seleções guiadas
Personalização sem complexidade técnica

Funcionalidades em expansão:

Plugins
Mods
Datapacks
Mundos
Minecraft Bedrock
Hytale

Sem abrir mão de controle operacional.

Sustentabilidade financeira

O modelo adotado é simples:

Anúncios para custear operação

Princípios aplicados:

Não bloquear uso com adblock
Remover anúncios abusivos
Priorizar experiência

O projeto não foi criado para maximizar lucro.

Foi criado para ser sustentável.

Estrutura de execução

Hoje o desenvolvimento é conduzido por uma equipe extremamente enxuta.

Processo atual:

Changelog ativo
Entregas incrementais
Planejamento discutido a cada ciclo

Resultados concretos

Atualmente (na data deste post) a plataforma já registrou:

1200+ usuários
1000+ comunidades
1050+ servidores criados
Pico de 20–25 servidores simultâneos

Tudo rodando em infraestrutura própria.

Considerações finais

A infraestrutura do ceu.gg não foi construída para parecer grande.

Foi construída para funcionar.

Ela combina:

Datacenter próprio
Virtualização controlada
Kubernetes
Engine de provisionamento própria
Backend estruturado com DDD
Observabilidade desde o início

É uma base técnica sólida.

E, principalmente, é um ambiente real onde arquitetura, operação e produto evoluem juntos.

Fechamento

A infraestrutura do ceu.gg continua evoluindo em ciclos curtos, sempre priorizando estabilidade, simplicidade e aprendizado contínuo.

Se você se interessa por desenvolvimento, arquitetura, backend e infraestrutura, acompanhe meu trabalho:

GitHub: github.com/filipebsmaia
Site pessoal: filipebsmaia.dev