Deploy e builds

Se a branch tem um arquivo Dockerfile na raiz do repositório (ou no diretório raiz do projeto), o build usa ele. Sem Dockerfile, a CLAUDO detecta a linguagem sozinha (Node, Python, Go, PHP, Ruby e outras) e monta a imagem. Dockerfile com outro nome ou em outra pasta, como Dockerfile.prod ou docker/Dockerfile: informe no campo Dockerfile da Configuração do projeto. Com o campo preenchido e o arquivo ausente na branch, o deploy é recusado em vez de cair na detecção.

Dockerfile com LABEL traefik.* é recusado: o roteamento é configurado pela CLAUDO. Imagem que traz rótulo do Traefik (inclusive da imagem de base) é parada por segurança; num preview, o preview é apagado e os previews do projeto são desligados até você ligar de novo. Segunda parada da produção em 30 dias suspende a organização.

Em Configuração → Projeto, todos opcionais:

Os comandos de build e de start usam o que o shell aceita sem variáveis nem redirecionamento: encadeie com &&, e evite $, ;, | sozinho e crase. O comando depois do deploy aceita qualquer linha de shell.

O campo Comando depois do deploy roda uma vez a cada deploy, dentro do contêiner da versão nova, com as mesmas variáveis dela. Serve para migrations e tarefas de liberação, como npx prisma migrate deploy, npx drizzle-kit migrate, python manage.py migrate ou php artisan migrate --force.

• Roda depois que a versão nova entra no ar: por alguns segundos ela atende com o banco ainda sem a migration. Escreva migrations que as duas versões aguentem (acrescentar coluna antes de usar, apagar só no deploy seguinte).
• O deploy aparece como Pronto logo que a versão nova sobe, antes de o comando terminar. Se o comando falhar, a versão nova continua no ar e o erro aparece no fim do log do build.
• Para não trocar de versão quando a migration falha, rode a migration antes de subir o servidor: no CMD do Dockerfile (com Dockerfile próprio ou imagem pronta) ou no comando de start (sem Dockerfile). Com o teste de saúde, a versão antiga fica no ar até a nova responder.
• Roda toda vez que uma versão sobe: deploy, Reiniciar, Ligar aplicação, voltar versão e as mudanças que recriam o contêiner (domínio, volume). Sempre o comando de agora, e precisa aguentar rodar mais de uma vez, como as ferramentas de migration já fazem.
• Uma linha só; para vários comandos, use &&.

Também roda em cada preview de pull request, com as variáveis de Preview. Se o Preview aponta para o mesmo banco da produção, a migration do pull request roda nele antes de você juntar. Use um banco de teste nas variáveis de Preview. O preview usa o Dockerfile e os comandos do último deploy de produção: mudou a configuração, faça um deploy para os previews seguirem.

A aplicação precisa escutar em 0.0.0.0 na porta da variável PORT. Para outra porta, cadastre PORT em Production. Sem ela, vale 3000.

Para um robô do Discord ou do Telegram, um consumidor de fila ou qualquer processo que não atende pela web, crie o projeto como Worker. Ele é publicado do mesmo jeito (repositório, Dockerfile ou imagem, variáveis, deploy a cada push, logs, alertas de log, métricas, bancos e volumes), mas não ganha endereço: nem o da plataforma, nem domínio próprio. A cada deploy a versão antiga para antes de a nova subir, para dois processos não rodarem juntos com o mesmo token (alguns segundos sem o robô). Por isso não tem senha de acesso, página de status, previews, analytics nem teste de saúde. O monitoramento confere a cada minuto se o processo está rodando: três conferências paradas (processo que parou, que reinicia sem parar ou que sumiu) abrem um incidente, com e-mail e webhook, e duas rodando fecham. Para erros que não derrubam o processo, use os alertas de log.

O tipo é escolhido ao criar o projeto e dá para trocar em Configuração do projeto até o primeiro deploy. Pelo terminal: claudo projects create <nome> --worker; pelo assistente: create_project com kind worker.

Com um caminho no campo Teste de saúde, o deploy sobe a versão nova ao lado da antiga, espera o caminho responder de dentro do container e só então desliga a antiga. Se a nova não responder em cerca de 105 segundos, ela é descartada, o deploy fica Falhou e a versão anterior continua no ar.

• O caminho começa com / e usa só letras, números e / - _ . ~ % , ;.
• Qualquer resposta abaixo de 400 conta como saudável (redirecionamento também).
• Com Dockerfile próprio, a imagem precisa ter curl ou wget. Sem Dockerfile, eles já vêm na imagem.
• Vale a partir do próximo deploy. Vazio, a versão nova entra assim que sobe.

export function GET() {
  return Response.json({ status: "ok" });
}

Depois do primeiro deploy pelo painel, cada push na branch de produção publica sozinho. Ligar o repositório não publica nada por si só. Se um deploy de push (ou de variável que mudou) falhar, Dono e Administradores recebem um e-mail, uma vez até um deploy dar certo; a versão anterior continua no ar.

No GitHub, o commit publicado ganha o status CLAUDO Production · <projeto>: verde quando entra no ar, vermelho se falhar, com o link do deploy no painel (em monorepo, um por projeto). Aparece no commit, no pull request juntado e na branch. Voltar versão e reiniciar não mexem no status. Precisa da conta do GitHub conectada (o repositório público não tem como escrever no GitHub).

Em monorepo, use Pastas que disparam deploy: padrões separados por vírgula, relativos à raiz do repositório. Push que não muda nada neles fica no histórico como Cancelado ("Ignorado: ..."), sem build.

O botão de deploy, a volta de versão e o deploy por mudança de variável publicam sempre. Quando o GitHub não informa os arquivos do push (branch nova, push enorme), publica.

Para um CMS publicar o site ao salvar um texto, um CI publicar depois dos testes ou um agendador de fora publicar todo dia: na Configuração do projeto, em Ganchos de deploy, dê um nome (quem vai chamar) e clique em Criar gancho. A URL aparece uma vez só; guarde onde o serviço vai usar.

curl -X POST https://claudo.com.br/api/hooks/deploy/claudo_dh_…

• Só POST publica: abrir a URL no navegador ou colar num chat (que faz GET) não muda nada.
• Publica a branch de produção (ou a imagem) com as variáveis de Production, como o botão. Aplicação parada pela equipe não liga por gancho.
• Quem tiver a URL consegue publicar: trate como senha. Vazou? Apague o gancho e crie outro; a URL antiga para na hora.
• Com um deploy ainda na fila, a chamada entra nele (resposta 202), que já publica a versão mais nova: o CMS que salva cinco vezes seguidas gera um deploy. Falha ao preparar responde 502; o motivo fica no painel.
• Até 10 ganchos por projeto, 30 chamadas por hora por gancho e 120 por hora de um mesmo endereço de origem. O histórico mostra o nome do gancho em cada deploy.
• Gancho criado por um token ou por um assistente de IA continua valendo se o token for revogado: confira a lista e apague o que não usa.
• Pelo terminal: claudo hooks create <projeto> <nome>, claudo hooks list <projeto> e claudo hooks rm <projeto> <id>.

Para site em construção, homologação com um cliente ou ferramenta interna: na Configuração do projeto, em Senha de acesso, escolha usuário e senha e clique em Ligar senha. O navegador passa a pedir os dois antes de qualquer página, em todos os domínios do projeto e nos previews de pull request.

• Com a aplicação no ar, ela sobe de novo na hora, sem build (a mesma versão). Parada, a senha vale quando ela for ligada; com deploy em andamento, no próximo deploy ou reinício. Os previews novos já pedem a senha em todos os casos.
• Previews já abertos passam a pedir a senha no próximo push do pull request.
• Tudo que chama o site também precisa da senha: webhooks de pagamento (Asaas, Stripe, Mercado Pago), apps, robôs de busca e a CLAUDO Queues entregando mensagens. Rotas de API que recebem chamadas de fora não funcionam com a senha ligada.
• O monitoramento da CLAUDO entra com a senha: queda continua sendo queda. Se o site pedir uma senha diferente da guardada (por exemplo, trocada durante um deploy), conta como queda até ela valer: faça um deploy ou Reiniciar.
• Usuário com letras sem acento, números e . _ -; senha de 8 a 72 caracteres, sem acento. A senha não aparece de novo: para mudar, grave outra. Tirar senha volta a abrir o site.

Pelo terminal: claudo protect <projeto> <usuário> (pede a senha sem mostrar) e claudo protect <projeto> --off. Por IA: set_access_protection e remove_access_protection.

Cada projeto publica uma branch. Para um ambiente de staging, crie outro projeto (por exemplo, "Loja staging"), ligue o mesmo repositório com a branch develop e cadastre nele as variáveis de staging, de preferência com um banco próprio. Cada push em develop publica o staging; cada push na branch de produção, o projeto principal.

• Cada deploy tem uma página com o status, o commit e Logs do build.
• Cancelar deploy interrompe um deploy na fila ou em build.
• O servidor faz um build por vez em cada aplicação. Um deploy pedido durante outro aparece como esperando o deploy anterior e sai sozinho quando aquele termina; vários pedidos seguidos viram um só, que publica a versão mais nova da branch.
• sem cache, ao lado de Fazer deploy de novo, constrói do zero, sem reaproveitar nada do build anterior: mais lento, para quando o build insiste num erro que não está no código. Pelo terminal: claudo deploy <projeto> --no-cache.
• Voltar para esta versão aparece num deploy Pronto: a imagem guardada volta ao ar em segundos, sem build. O próximo push publica de novo o código da branch.
• Na página do projeto, Reiniciar sobe de novo a versão que está no ar, sem build, com as variáveis e o comando depois do deploy de agora; o código novo do branch só vai por deploy. Parar aplicação tira o endereço do ar: o monitoramento não conta como queda, e push e deploy por variável não a ligam; bancos e volumes ficam. Ligar aplicação sobe a mesma versão (ou faça deploy). Os dois aparecem na lista de deploys. Pelo terminal: claudo restart, claudo stop e claudo start.
• Logs da aplicação ficam em Logs, no projeto. Ao vivo mostra as últimas 300 linhas do container no ar. Histórico busca por texto e período no que a CLAUDO guardou, lido a cada minuto: Free 1 dia, Pro 7, Scale 14. Uma aplicação que imprime mais de 500 linhas num minuto pode perder parte delas. Pelo terminal: claudo logs <projeto> --search <texto>. Para guardar por mais tempo ou criar alertas, mande os logs para um serviço de logs (Monitoramento e webhooks → Envio de logs).

Conta como aplicação o projeto que já teve deploy; deploys seguintes não contam. Os números do seu plano ficam em Billing e Usage.