🌐Infra: sites, bancos de dados, buckets, domínios, servidores

A página Infra responde a "o que está onde, e está funcionando?": cada site, banco de dados, bucket, domínio e servidor - neste servidor, nos seus outros servidores, na Cloudflare e na Hostinger - com seu status, seus vínculos (este domínio -> este servidor -> este site -> este app -> este repositório) e o projeto do Harness ao qual pertence.

Ela vem desativada por padrão: ative em Configurações -> Recursos -> Página Infra. Uma entrada Infra aparece na barra lateral (atalho G e depois I).

Como funciona

O Harness lê tudo: este servidor diretamente, seus outros servidores por SSH (somente leitura), a Cloudflare e a Hostinger com suas chaves de API. Ele liga o que encontra: um domínio ao seu site, um site ao seu app, ao seu banco de dados e ao seu repositório git.
Ele vigia para você: cada endereço é verificado (ele responde? o certificado é válido?), assim como as datas de expiração dos domínios e o espaço em disco, a cada 15 minutos (infra_refresh_min) ou quando você clica em Atualizar. Um problema vai para o topo da página e para suas notificações, uma única vez por incidente.
Você cria pedindo ao Claude: "coloque esta pasta no ar", "crie um banco de dados para o meu app"... O Claude segue as receitas padrão (abaixo) e o resultado aparece na página.

A página em si nunca altera seus sites ou bancos de dados; a única coisa que ela faz por conta própria é conectar um servidor (veja Outros servidores). Para mudar algo, peça ao Claude: cada linha tem uma caixa Perguntar ao Claude.

A página

Visão geral: uma caixa "Como funciona" (com um link para esta página) (feche-a com ×, traga-a de volta com Como funciona no canto superior direito), a contagem de cada tipo com o que está fora do ar ou a verificar, a lista Para olhar, e O que o Harness lê: cada fonte com o que ela fornece e, quando algo está faltando, o próximo passo (Adicionar a chave ..., Adicionar estas permissões para um token da Cloudflare que não consegue ler tudo, Conectar para uma VPS ainda não lida).
Sites, Bancos de dados, Buckets, Domínios: agrupados pelo lugar onde ficam. Domínios -> Adicionar um domínio vigia um domínio de qualquer registrador. Busque, filtre por projeto, mostre as linhas ocultas com o botão de olho.
Servidores: um cartão por servidor com seu endereço, seu sistema, memória / disco / CPU em uso e quantos sites, bancos de dados e buckets rodam nele.
Clique em qualquer linha para ver seus detalhes, ao que ela está ligada, seu repositório (abre a página Git), seu painel da Cloudflare / Hostinger, um projeto, uma nota, para ocultá-la ou para perguntar ao Claude sobre ela.

O que ele lê

Fonte	O que você vê	Precisa de
Este servidor	Sites do Caddy (ou nginx) e o que há por trás de cada um (pasta, porta do app, serviço systemd, contêiner Docker, repositório git), bancos de dados PostgreSQL / MySQL (inclusive dentro do Docker), arquivos SQLite, buckets Garage, disco, memória	nada
Seus outros servidores	o mesmo, lido por SSH	`python3` lá e acesso SSH: veja Outros servidores
Qualquer domínio	registrador e data de expiração (serviço público RDAP), quem serve o seu DNS (OVH, GoDaddy, Namecheap, IONOS, Gandi, o2switch...), quem hospeda o seu endereço (um dos seus servidores, Vercel, Netlify, GitHub Pages, Shopify, Cloudflare, Webflow, Wix, Squarespace...)	nada (DNS público); adicione os domínios que nenhum provedor lista em Domínios -> Adicionar um domínio
Cloudflare	domínios (zonas) e seu DNS, Workers e seus endereços, Pages, buckets R2 e seus endereços públicos, bancos de dados D1, domínios do Registrar	a chave `CLOUDFLARE_API_TOKEN` (+ `CLOUDFLARE_ACCOUNT_ID`)
Hostinger	domínios com sua data de expiração, VPS, zonas DNS	a chave `HOSTINGER_API_TOKEN`
Vercel (beta)	projetos com seu deploy de produção (estado, data, repositório git, framework), seus domínios; domínios comprados na Vercel com sua data de expiração; todas as equipes que o token enxerga	a chave `VERCEL_TOKEN`
Netlify (beta)	sites com seu último deploy e repositório git, zonas DNS da Netlify	a chave `NETLIFY_AUTH_TOKEN`
Supabase (beta)	cada projeto: seu banco de dados (estado, região, versão do Postgres; um projeto gratuito pausado aparece como "pausado"), seus buckets de Storage, suas Edge Functions, ligados entre si	a chave `SUPABASE_ACCESS_TOKEN`
GitHub Pages (beta)	os sites Pages dos seus repositórios, seu endereço e o estado do build	os tokens do GitHub que já estão nas suas chaves (página Git)

As chaves ficam em Configurações -> Chaves (a página Infra tem links para elas). O Harness apenas lê com elas. Dê direitos de leitura onde o provedor permitir (Cloudflare, GitHub); os tokens da Vercel, Netlify e Supabase não podem ser limitados à leitura: deixe-os não expostos às sessões (o padrão em Chaves) para que somente a página Infra os use. Um token sem um dos direitos apenas oculta aquela parte: a página diz qual.

As consultas de DNS público passam por um resolvedor público via HTTPS (o 1.1.1.1 da Cloudflare por padrão): ele vê os nomes de domínio consultados, nada além disso. Cada nome é consultado no máximo a cada 6 horas.

Criando as chaves

Cloudflare: dash.cloudflare.com/profile/api-tokens -> Create token -> Custom, direitos (Read): Zone, DNS, Workers Scripts, Workers Routes, Cloudflare Pages, Workers R2 Storage, D1, Registrar; adicione DNS Edit se quiser que o Claude crie registros DNS para novos sites.
Hostinger: hPanel -> Profile -> API -> novo token.
Vercel: vercel.com/account/settings/tokens -> Create token, escopo "Full account" para ver todas as equipes (a Vercel não tem token somente leitura: o Harness apenas lê).
Netlify: User settings -> Applications -> Personal access tokens -> New access token.
Supabase: supabase.com/dashboard/account/tokens -> Generate new token.
GitHub Pages: nada mais, se a página Git já mostra seus repositórios.

Beta significa escrito a partir da referência oficial da API do provedor e testado com as respostas documentadas, mas ainda não visto em uma conta real: se uma linha mostrar um erro, pergunte ao Claude a partir dessa linha (ele vê o erro) e avise-nos.

Meu provedor não está na lista

Domínios: não é preciso nada. Adicione o domínio em Domínios -> Adicionar um domínio (ou peça ao Claude "vigie o domínio example.com"): seu registrador, data de expiração, provedor de DNS e hospedagem são lidos a partir de informações públicas, e ele é ligado ao seu servidor quando aponta para ele. Os alertas antes da expiração funcionam da mesma forma.
Um servidor (OVH, DigitalOcean, Hetzner, Scaleway...): Adicionar um servidor, ele é lido por SSH como qualquer outro.
Uma plataforma (Render, Railway, Fly.io, Firebase, AWS...): seus sites continuam aparecendo por meio dos domínios (a página diz quem hospeda cada endereço). O suporte completo está planejado provedor por provedor.

Outros servidores

Uma VPS da Hostinger aparece sozinha assim que a chave da Hostinger está no cofre, com o nome VPS Hostinger. Se ela já aceita uma chave SSH deste servidor, o Harness a conecta por conta própria (a API da Hostinger diz qual chave, então nada é tentado às cegas). Caso contrário, abra-a e clique em Conectar: o Harness adiciona sua própria chave (harness-maxxing@<this server>) à conta root da VPS por meio da sua chave da Hostinger e depois a lê. Essa é a única alteração que a página Infra faz em um provedor; você pode remover a chave em hPanel -> VPS -> SSH keys.
Qualquer outro servidor: Adicionar um servidor (no topo da página) com seu endereço, usuário SSH e porta. Se nenhuma das chaves deste servidor for aceita lá, a janela mostra uma linha para você executar nesse servidor e, em seguida, Tentar novamente.
No painel de um servidor conectado: altere o nome exibido (o nome interno, usado nos links, nunca muda) ou Desconecte-o (nada muda no servidor).
Pelo terminal: maxxing infra server connect <IP or Hostinger VPS id>, server rename NAME "Label".

O Harness apenas lê os outros servidores (sites, portas e serviços, Docker, bancos de dados, buckets, disco, memória). O servidor precisa de python3 (todo Linux comum tem).

Status

OK (verde), A verificar (laranja): uma página respondendo 404, um certificado ou um domínio prestes a expirar, um registro DNS apontando para outro servidor que não o que serve o site, um disco quase cheio, um backup que falhou...
Fora do ar (vermelho): sem resposta, um erro de servidor (5xx), um domínio expirado, um recurso criado por uma receita que não é mais encontrado.

Os alertas vão para o feed de notificações (e para o Telegram quando a thread do feed está ativada): um site ou um servidor saindo do ar e voltando, um certificado expirando em até 14 dias, um domínio expirando em 30 e depois em 7 dias (quando não há renovação automática).

Criar coisas neste servidor

Peça ao Claude em palavras simples; ele segue uma receita fixa (skill maxxing-infra, comando maxxing infra) para que tudo seja feito da mesma forma, verificado antes de ser aplicado, e apareça na página:

"Coloque esta pasta no ar" -> https://<your Harness address>/<name>/, na hora, sem DNS. Essas páginas rodam isoladas (em sandbox): elas nunca podem tocar no Harness nem na sua sessão (um app por trás de um caminho assim nunca recebe o seu cookie do Harness e não pode definir um; arquivos ocultos como .env ou .git nunca são servidos; a raiz do workspace, o código, a pasta de estado e o .ssh não podem ser publicados). Perfeito para páginas, demos, relatórios, sites estáticos. Um app com login, carrinho ou cookies precisa do seu próprio endereço (shop.example.com): o Claude aconselha isso e cria o registro DNS na Cloudflare quando a chave permite.
"Crie um banco de dados para o meu app" -> PostgreSQL (instalado na primeira vez, acessível somente a partir deste servidor), um banco de dados e um usuário por app, seu endereço guardado em Chaves (DB_<NAME>_URL), com backup toda noite (tarefa "Infra: database backups", 7 cópias mantidas em /var/backups/maxxing-db).
"Crie um bucket" -> armazenamento S3 neste servidor (Garage), suas chaves em Chaves (S3_<NAME>_...), opcionalmente público em https://<your Harness address>/<name>/. Os arquivos ficam neste disco: para arquivos públicos grandes, a Cloudflare R2 é muitas vezes melhor, e o Claude avisa.
"Adicione meu outro servidor 203.0.113.7" -> o Claude o conecta (maxxing infra server connect); se ele ainda não aceita uma chave deste servidor, o Claude diz qual linha executar lá.

Nas conversas

Quando o Claude fala sobre recursos, ele adiciona um pequeno bloco infra que o app mostra ao vivo (status, link para a página):

```infra
site: shop.example.com
database: shop
```

Linhas: site, database, bucket, domain, server, worker, pages, id (um recurso cada), ou filtros project: acme, kind: database, location: <server>. Exibido quando a página Infra está ativada (caso contrário, o texto permanece).

Terminal

Segurança do `infra.json`

Os servidores de <workspace>/infra.json são acessados por ssh pelo próprio servidor, então o Claude não pode editar esse arquivo (ele está nas regras de negação de cada turno, como as configurações de pasta); use maxxing infra server add ou a página. Uma entrada escrita à mão que a CLI recusaria (usuário, host ou caminho de chave estranhos) é ignorada. Um provedor que não responde (Cloudflare, Hostinger, um servidor) apenas deixa a sua própria seção vazia: as verificações e os alertas do resto continuam.