Vender servidores de jogos com GameAP

O GameAP é um projeto pequeno. A 21 de agosto de 2026, o seu repositório GitHub tinha 60 estrelas, 9 forks e 2 contribuidores. Vale a pena dizê-lo em voz alta, porque isso fixa as expetativas: não existe à sua volta um grande ecossistema de módulos de faturação, scripts de aprovisionamento e tópicos de fórum. Quem faz correr o GameAP e quer vender o que ele aloja está, em grande medida, por sua conta.

Esta página trata de fechar essa lacuna. O Provibr liga-se a um painel GameAP e aprovisiona, controla e importa nele servidores de jogos. Tudo o que se segue foi medido num painel GameAP 4.4.2 real, e não copiado de uma lista de funcionalidades, incluindo os pontos em que o GameAP se comporta de forma diferente do que seria de esperar.

O que a integração cobre realmente

As duas linhas «não» não são esquecimentos, e as razões estão no fim.

Passo 1: o token de API

O GameAP autentica-se com um único token de API. Sem cliente OAuth2, sem par de chaves, sem sessão para manter viva: um portador, e é essa toda a credencial.

Importam quatro coisas a seu respeito.

Tem de ser criado por um administrador, e tem de conter a permissão de criação. Os tokens do GameAP têm âmbito definido. Um token sem admin:server:create lista servidores perfeitamente, mas não os pode criar nem eliminar. Vale a pena saber isto antes da primeira encomenda, porque um token com âmbito mas errado parece saudável até ao momento exato em que um cliente paga. O Provibr verifica a permissão de criação ao testar a ligação, não na primeira encomenda.

A eliminação depende dessa mesma permissão. Não existe qualquer âmbito server:delete no GameAP. Medimos uma eliminação bem-sucedida com um token que continha apenas admin:server:create mais os âmbitos de servidor comuns. Um único token cobre todo o ciclo de vida.

O token tem a forma id|secret. É a forma do Laravel Sanctum: um id numérico, uma barra vertical e um segredo de 48 caracteres. O Provibr conserva essa forma e recusa um token colado sem o id à frente: é um verdadeiro erro de cópia, e apanhá-lo aqui vale mais do que um 401 confuso mais tarde.

Não expira. A tabela personal_access_tokens do GameAP não tem coluna expires_at. É a credencial de longa duração mais limpa de todos os painéis que integrámos: o agente continua a funcionar durante meses sem que ninguém volte a introduzir o que quer que seja. Compare com painéis em que o segredo é uma palavra-passe e cada rotação se torna um pedido de suporte.

Uma nota prática: o GameAP mostra o token uma vez e depois guarda apenas um hash. Copie-o imediatamente. O Provibr também não o armazena, portanto reenviar as credenciais significa criar um novo token.

Passo 2: o transporte, e ser honesto quanto a ele

Uma instalação GameAP predefinida serve HTTP simples na porta 8025, com a 443 fechada. Não há campo de impressão digital TLS no formulário de credenciais, porque sem TLS não há certificado para fixar.

Isso funciona. Também significa que o token de API, e tudo o que a integração faz, circula em claro. Se isso importa (e num painel que aloja os servidores dos clientes provavelmente deveria), coloque à frente um reverse proxy com TLS. O agente valida então a cadeia de certificados normalmente, sem fixação.

Passo 3: o plano, e porque não há lista

Um servidor GameAP é construído a partir de um jogo (um título como samp ou minecraft) e de um game mod, que é o seu modelo. Juntos, correspondem aproximadamente ao que é um egg no Pterodactyl.

Eis a diferença mais nítida em relação a todos os outros painéis de jogos que suportamos: o Provibr não os pode listar por si. Com um token de agente com âmbito definido, /api/games, /api/game_mods e /api/nodes devolvem todos 403. A leitura do catálogo está restrita por papel a uma sessão de administrador, e nenhuma permissão de token a desbloqueia.

Portanto, não há menu pendente. Abra o seu próprio painel GameAP, leia o código do jogo e o id do mod, e escreva-os no plano. Um plano de jogo passa a conter esse código de jogo, esse id de mod e os limites de recursos, e a partir daí a encomenda é orientada por plano.

É mais escrita do que uma lista. É também a forma honesta: um menu pendente que não conseguíssemos preencher seria pior do que um campo que diz o que quer.

Passo 4: colocação e portas

Duas consequências decorrem desse mesmo 403.

O nó vem de uma definição, não do motor de colocação. O Provibr ordena os nós por capacidade livre quando pode: aqui não pode, porque não consegue de todo ler a lista de nós. Em vez disso, a integração transporta um id de nó, que é 1 num painel de um único nó. Num painel com vários nós, um servidor aterra no nó que se indicou, e nada é ordenado.

As portas vêm de um intervalo que se define. O GameAP não tem sistema de alocação próprio: nada distribui uma porta livre. O agente escolhe um conjunto livre de portas (jogo, consulta e RCON) a partir de um intervalo configurado na integração.

O que uma encomenda faz realmente

É aqui que o GameAP mais difere de um painel como o Pterodactyl, e onde uma integração ingénua se engana.

1. 01POST /api/servers escreve o registo na base de dados. Não instala nada.
2. 02Uma segunda chamada inicia a instalação, e o daemon do painel executa-a como tarefa assíncrona.
3. 03O Provibr sonda essa tarefa até esta atingir um estado final.
4. 04Depois o servidor arranca.

A regra decisiva: a resposta HTTP de uma ação significa apenas que a tarefa foi posta em fila. Não significa que teve êxito. Medimos um stop que voltou com erro devido a uma condição de corrida no anfitrião: cada servidor de jogo corre como a sua própria unidade systemd no nó, e systemctl stop pode perder uma corrida consigo próprio. O resultado da tarefa é a verdade; a resposta HTTP é um recibo. O Provibr lê a tarefa.

Mais duas realidades medidas a ter em conta no planeamento. Não há id externo nem chave de idempotência, e os nomes de servidor não são únicos: criámos dois servidores com o mesmo nome e obtivemos dois 201 com ids diferentes. O id devolvido pela chamada de criação é a única identidade que existe, o que significa que uma criação repetida produz silenciosamente um duplicado. E o ambiente de instalação não está uniformemente completo: uma instalação de TeamSpeak 3 num painel padrão falhou porque faltava o lbzip2 para a extração do .tar.bz2, enquanto uma instalação SA-MP na mesma máquina correu sem problemas. Conte com «a instalação funciona para um jogo e não para outro» como categoria de suporte.

Suspender: leia isto antes de contar com isso

Quando o Provibr suspende um servidor de jogo (para impor um limite de capacidade), para o servidor e marca-o como bloqueado no painel.

Ambas as metades são necessárias, e eis porquê: o indicador blocked do GameAP não impõe nada. Definimos blocked num servidor SA-MP em funcionamento e ele manteve-se online, respondendo a consultas de jogo em direto. Enviámos depois um arranque a um servidor bloqueado e obtivemos uma tarefa normal. O indicador é administrativo.

Por isso, o Provibr para o servidor para impor realmente o limite. Mas qualquer pessoa com acesso direto ao painel GameAP pode voltar a arrancá-lo. O bloqueio é tanto um conceito do Provibr como do painel, e preferimos escrevê-lo a deixar que o descubra durante o seu primeiro excesso.

O que o Provibr não faz aqui

Sem consola. O GameAP tem uma, sobre um websocket, mas assenta num token efémero à parte, obtido pelo seu próprio passo de autenticação, e no seu próprio protocolo de tramas, um caminho diferente do túnel que o nosso agente partilha com os outros painéis de jogos. É trabalho a sério, não um interruptor. Ativar o separador antes de esse trabalho existir prometeria um túnel que não está lá.

Sem gráficos de utilização. O GameAP não indica, por servidor, CPU, memória, disco nem rede. Não há endpoint. Um gráfico fixo a zero parece uma medição, e «nenhuma medição» e «nenhuma utilização» não são a mesma coisa, portanto não mostramos nada.

Sem gestão do painel. Os nós, os ficheiros, os utilizadores e o próprio painel continuam a ser seus. Aquilo de que a integração trata é um servidor de jogo no painel.

O que isto muda para um pequeno alojador

Se é o GameAP que faz correr, a escolha costuma ser apresentada assim: «manter o painel e faturar à mão» ou «passar para algo que um sistema de faturação já fala». É uma falsa escolha, e cara: migrar um painel cheio de servidores de jogo em produção não é coisa para um fim de semana.

O Provibr liga-se a painéis de controlo, hipervisores e painéis de jogo lado a lado. Não é preciso escolher um. Mantenha o GameAP para os jogos que já aloja, acrescente ao lado o que precisar, e faça correr a encomenda, a contagem de capacidade e a suspensão por falta de pagamento sobre todos eles a partir de um único lugar.