Crunu e Vercel: hospede o servidor, envie variáveis

Dois jeitos de o Crunu funcionar com a Vercel

• Hospedar o servidor do Crunu na Vercel. Se a sua equipe já faz deploy lá, o servidor do Crunu tem um build para a Vercel que usa Postgres no Neon. Esta parte é embutida: um script faz o deploy.
• Enviar valores para os seus próprios projetos na Vercel. O Crunu não tem sincronização embutida com as variáveis de ambiente da Vercel. Um pipeline pode enviá-las com uma receita curta, mostrada abaixo.

O próprio Crunu roda na nuvem em app.crunu.com, então você só precisa da primeira parte se quiser um servidor próprio.

Hospede o servidor na Vercel

Você precisa de Node.js 24, da CLI vercel com o vercel login feito, de um banco de dados Neon com o endereço com pooling em DATABASE_URL 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/vercel/deploy.sh --project vault-company --prod

O script confere o .env, monta o servidor com o cliente web embutido, cria o projeto se for preciso, grava as variáveis de ambiente com valores passados pelo stdin e faz o deploy da saída já montada. O próprio servidor aplica as migrações de esquema no banco de dados dele.

Sem --prod, o script faz o deploy de uma preview com banco de dados próprio e chave do servidor própria, definidos como PREVIEW_DATABASE_URL e PREVIEW_SERVER_KEY. Um build de preview rodaria as migrações no banco de dados a que estivesse conectado, então o script se recusa a apontar uma preview para os dados de production, a menos que você passe --preview-with-production-db.

Agenda da limpeza

A limpeza de registros expirados roda num cron job da Vercel, só em deployments de production com CRON_SECRET definido. O padrão é uma vez por dia, porque o plano Hobby não permite uma agenda mais frequente; confira os limites atuais dos planos da Vercel. A expiração de sessões, links e acessos break-glass não depende dela, porque cada requisição os confere. Alguns alertas dependem. Se você usa restrições de rede com passes de máquina, rode a limpeza a cada minuto ou pelo menos a cada 5 minutos, o que exige o Vercel Pro, e passe a agenda em cada deploy:

sh deploy/vercel/deploy.sh --project vault-company --prod --cron "* * * * *"

Envie valores para a Vercel a partir do CI

Se um projeto seu na Vercel guarda as variáveis na Vercel, um pipeline pode copiá-las do Crunu. Use um token de production separado, com um vínculo de CI (OIDC) ao branch main e ao ambiente de deployment production, para que o token só funcione nesse job. Quem tem a função Owner aprova o acesso ao production para ele.

crunu run --env web-app/production -- sh -c 'printf "%s" "$DATABASE_URL" | vercel env add DATABASE_URL production --force'

O crunu run descriptografa o ambiente em memória e passa DATABASE_URL ao comando, que o entrega ao vercel env add pelo stdin, nunca como argumento. Cada execução fica registrada no log de auditoria do Crunu: quem, quando, de qual endereço e qual versão.

Veja também

• Hospedagem própria
• Vercel na documentação
• CI/CD no Crunu
• GitHub Actions