Faça o deploy de um projeto pela primeira vez
Criar uma aplicação envia uma pasta do seu computador, então exige o servidor local (Claude Code, Codex, Claude Desktop, Cursor e outros clientes que executamnpx @vertracloud/mcp). Inicie o agente na pasta do projeto.
Faça deploy desta pasta na Vertra Cloud como um app Node chamado support-bot, com 512 MB, e espere até ficar online.
A criação é assíncrona: o app começa em
building e passa para up ou down. Se terminar em down,
last_build_error diz o motivo e o agente pode corrigir o código e tentar de novo. Para atualizações seguintes:
Faça deploy da pasta atual no support-bot com a mensagem “fix login timeout”.
Isso executa deploy_app (apps:files), que mantém o histórico de releases para você poder fazer rollback.
Descubra por que uma aplicação caiu
Por que o orders-api caiu? Leia as últimas 300 linhas de log e o uso de memória, e me diga a causa antes de
mudar qualquer coisa.
Tudo aqui é só leitura, então uma chave só com
apps:read basta. As linhas de log chegam ao agente marcadas como conteúdo
não confiável: uma linha impressa pela sua aplicação é lida como dado, nunca como instrução. Pedir a causa antes de qualquer
mudança impede que o agente reinicie ou faça redeploy por conta própria. O
guia de depuração de crash explica as causas comuns.
Se o agente estiver rodando na pasta do projeto, o pedido seguinte fecha o ciclo:
Corrija a causa no código, rode os testes e faça deploy no orders-api.
Crie um banco de dados e conecte a uma aplicação
Crie um PostgreSQL de 1 GB chamadoorders-db, definaDB_HOST,DB_PORTeDB_USERnoorders-apie me mostre como o código deve se conectar.
A string de conexão vem com um placeholder
<password>: a API nunca retorna a senha do banco de dados, então ela não
entra na conversa. Copie-a da página do banco de dados no dashboard e adicione você mesmo como variável (por
exemplo DB_PASSWORD). O app também precisa do certificado de cliente do banco de dados: veja
Conectar um banco de dados.
Volte para a versão anterior
O orders-api começou a falhar depois do último deploy. Mostre o histórico de releases e o que um rollback mudaria,
depois faça rollback para a última versão que funcionava.
rollback_app é marcada como destrutiva, então o cliente pede que você confirme antes de ela executar. Veja
Rollback e deploys sem downtime.
Tire um snapshot antes de uma mudança arriscada
Tire um snapshot do orders-db antes de eu rodar a migração. Se a migração falhar, restaure.
create_snapshot e restore_snapshot usam snapshots:write; list_snapshots usa snapshots:read. Restaurar
substitui os dados atuais, então o cliente pede que você confirme. Veja Backups e snapshots.
Leia o tráfego do seu site
Compare o tráfego desta semana no shop-web com o da semana passada. Quais caminhos têm mais erros 5xx?
get_app_analytics e get_app_analytics_errors usam apps:read. Caminhos e referers vêm dos seus visitantes e também
chegam ao agente como conteúdo não confiável. Veja Web Analytics.
Consulte como a plataforma funciona
Segundo a documentação da Vertra Cloud, quanto armazenamento um PostgreSQL de 2 GB recebe?
get_docs lê esta documentação e não precisa de escopo. É assim que o agente confere um limite ou um código de erro em vez de
chutar.
Mantenha o agente seguro
- Comece com escopos de leitura.
apps:read,databases:readesnapshots:readcobrem a investigação. Adicione escopos de escrita quando precisar, de preferência em uma chave separada. - Deixe as confirmações de ações destrutivas ligadas. Excluir, parar, reiniciar, sobrescrever um arquivo, alterar uma variável e fazer rollback são marcados como destrutivos, e o cliente pergunta antes de cada um. Não os permita de forma permanente.
- Os valores das variáveis nunca chegam ao agente.
list_envsretorna só os nomes, eset_envnão repete o valor. - Revogue o que não usa mais. Cada chave, inclusive a criada por uma conexão OAuth, aparece em Configurações → Chaves de API. Uma conta tem até 10 chaves.