Primeiros passos

1. Crie a conta em https://claudo.com.br/criar-conta. Ela já nasce com uma organização pessoal; para trabalhar em equipe, crie uma organização em Team. Lá, quem administra pode exigir a verificação em duas etapas de todos.
2. Em Projects, clique em Novo projeto, dê um nome e clique em Criar projeto.
3. Na Configuração do projeto, em Repositório, clique em Conectar GitHub e autorize a CLAUDO na sua conta ou organização do GitHub (só quem administra a organização na CLAUDO faz isso).
4. Escolha o repositório e a branch de produção e clique em Ligar repositório.
5. Se a aplicação precisa de variáveis (chaves, conexão de banco), cadastre em Variáveis antes do primeiro deploy.
6. Na página do projeto, clique em Fazer deploy. O status vai de Na fila para Buildando, Publicando e Pronto.
7. Pronto: o endereço aparece no projeto. A partir daí, cada push na branch publica sozinho.

A aplicação precisa escutar na porta da variável PORT. Sem PORT cadastrada, a CLAUDO usa 3000 e entrega PORT=3000 à aplicação.

Sem conectar conta: em Repositório, abra Repositório público do GitHub ou do GitLab, sem conectar a conta, cole o endereço (como https://github.com/dono/repo ou https://gitlab.com/grupo/projeto, com subgrupos) e clique em Ligar repositório público. Serve para qualquer repositório público do GitHub ou do gitlab.com; cada versão nova sai pelo Fazer deploy (ou claudo deploy, ou um gancho de deploy), porque sem a conta ninguém avisa a CLAUDO dos pushes, e não há preview de pull request. Trocar de origem (conta do GitHub, público do GitHub, público do GitLab) recria a aplicação: com volume no projeto, a troca é recusada, para os dados não começarem vazios.

Para o GitLab publicar a cada push: na Configuração do projeto, crie um gancho de deploy; no GitLab, em Settings → Webhooks do projeto, cole a URL do gancho, marque Push events e escreva a branch de produção no filtro de branch. Cada push nela publica de novo.

Sem repositório, com uma imagem pronta: abra Imagem Docker pública, digite a imagem (como n8nio/n8n:latest ou ghcr.io/dono/app:v2) e clique em Ligar imagem. Vale imagem pública do Docker Hub, ghcr.io, quay.io, public.ecr.aws, registry.gitlab.com ou mcr.microsoft.com, com versão linux/amd64. Cada deploy confere a tag no registro e publica a versão exata daquele momento; para atualizar, faça deploy de novo. A porta é a do EXPOSE da imagem, a não ser que você defina PORT nas variáveis. Pelo terminal: claudo image <projeto> <imagem>.

• Domínio próprio: Domínios e HTTPS.
• Banco de dados: Bancos de dados; a conexão chega sozinha às variáveis.
• Troca de versão sem queda: defina o teste de saúde em Deploy e builds.
• Avisos de deploy e de queda no Slack, Discord, Telegram ou WhatsApp: Monitoramento e webhooks.
• Automatizar pelo terminal ou por um assistente de IA: API e CLI e Conectar IA.

Em Team, Dono ou Administrador clica em Exigir verificação em duas etapas. Antes, você e pelo menos um dono precisam ter a de vocês ligada (Settings → Verificação em duas etapas). Daí em diante, só entra na organização, pelo painel, pela API ou por um assistente de IA, quem tem a verificação ligada.

• Quem ainda não tinha fica sem acesso, vê um aviso no painel e pode sair da organização.
• Depois que a pessoa liga a dela, quem administra recebe um e-mail e libera em Team com Liberar acesso. Antes de liberar, confirme com a pessoa por outro canal que foi ela: quem tivesse só a senha dela também conseguiria ligar.
• Convite para a equipe só é aceito por quem já tem a verificação ligada; a pessoa entra direto, sem esperar liberação.
• Token de API ou app conectado (Claude, ChatGPT) criado antes de a pessoa ligar a verificação não entra na equipe: crie um token novo ou conecte o app de novo.
• Ligar a verificação pede a senha e encerra as suas outras sessões. Ninguém desliga a própria estando numa equipe que exige.