Hospede o servidor do Crunu no Google Cloud Run

O que o Crunu faz no Cloud Run

O Crunu roda na nuvem em app.crunu.com, então você não precisa de um servidor próprio para começar. Se a sua infraestrutura está no Google Cloud, o servidor do Crunu faz o deploy no Cloud Run com um script, guarda os segredos no Secret Manager e usa Postgres no Cloud SQL ou no Neon.

O servidor é cego no Cloud Run como em qualquer outro lugar: o banco de dados guarda texto cifrado, chaves públicas, documentos assinados e metadados, nunca uma chave que descriptografe um valor.

Deploy

Você precisa de Node.js 24, do gcloud com login feito, de um projeto com faturamento, de um banco de dados Postgres e de um arquivo .env criado pelo server-init. Os comandos rodam a partir do diretório do servidor do Crunu, onde ficam os scripts de deploy.

node scripts/server-init.mjs --origin https://vault.company.example --database-url env:DATABASE_URL
sh deploy/gcp/deploy.sh --project my-project --region europe-west1 --service vault

O script confere o .env, ativa as APIs do Cloud Run, do Artifact Registry e do Secret Manager, monta uma imagem linux/amd64 no Artifact Registry, guarda os segredos do servidor no Secret Manager e cria uma conta de serviço que só consegue ler esses segredos. Depois, faz o deploy do serviço.

• Segredos fixos por revisão. Uma nova versão de segredo só aparece quando um valor muda, e o serviço referencia os segredos pelo número da versão, não como latest. Cada revisão mantém os valores com que foi publicada, então voltar o tráfego para uma revisão mais antiga traz de volta também os segredos dela.
• Cloud SQL pelo socket. Use um endereço como postgres://user:password@/database?host=/cloudsql/project:region:instance. O script vincula a instância ao serviço e dá à conta de serviço dele a função Cloud SQL Client.
• Configurações mescladas. As variáveis de ambiente são mescladas, então os valores que você definiu à mão no serviço continuam. As variáveis que não estão mais no .env são listadas e só são removidas com --prune.
• Endereços dos clientes. Por padrão, os clientes chegam direto ao serviço. Atrás do balanceador de carga externo do Google, faça o deploy com --trust-proxy xff:2: o serviço passa a aceitar tráfego só do balanceador, e o PUBLIC_ORIGIN precisa ser o endereço do balanceador.

A limpeza só roda com tráfego

As máquinas que rodam o agente crunu consultam o servidor a cada minuto por padrão, então, com máquinas online, a limpeza roda junto, mais ou menos a cada 5 minutos.

Revisões antigas

O script de deploy não marca revisões com tags, então as mais antigas não têm endereço próprio. Se você marcou revisões à mão, remova essas tags, porque uma revisão antiga com tag funciona com o mesmo banco de dados e os mesmos segredos:

gcloud run services update-traffic <service> --region <region> --remove-tags <tag>

Veja também

• Hospedagem própria
• Google Cloud Run na documentação
• Mudar de plataforma
• Docker