Implante um aplicativo do Claude Code em 60 segundos — sem painel, sem CAPTCHA

Nota: Eu sou o criador do openpouch. Este é um guia, escrito honestamente — é uma prévia técnica e serei claro sobre os limites. Feedback é muito bem-vindo.

Seu agente de codificação pode escrever o aplicativo. Ele pode escrever os testes. Então ele clica em implantar — e a nuvem pede para ele clicar em um hidrante.

Esse é o problema que ninguém projetou: cada alvo de implantação assume um humano em um navegador. CAPTCHAs, "verifique se você é humano", alternâncias apenas no painel, fluxos de OAuth que terminam em uma aba sem interface. Um agente que pode enviar software não consegue passar por uma barreira de bot construída para parar bots.

openpouch é o oposto disso: um comando para uma URL ao vivo, sem conta, sem painel, sem etapa de verificação humana em lugar algum. Ele é enviado como um CLI e um servidor MCP, então se integra ao Claude Code (ou Cursor, Codex, OpenClaw, …) como ferramentas nativas. Aqui está a versão de 60 segundos do Claude Code.

1. Adicione o servidor MCP

claude mcp add openpouch -- npx -y @openpouch/mcp

É isso — um servidor MCP sem dependências, puxado sob demanda via npx. Ele expõe todo o ciclo de vida de implantação como 13 ferramentas (openpouch_deploy, openpouch_verify, openpouch_logs, openpouch_inspect, openpouch_rollback, openpouch_list, …). Não há deliberadamente nenhuma ferramenta approve — aprovar uma implantação em produção é apenas para humanos, em qualquer estrutura. Um agente literalmente não pode aprovar sua própria implantação em produção. Pré-visualizações, no entanto, ele simplesmente envia.

Não pode anexar servidores MCP durante a sessão? Você pode provar todo o conjunto de ferramentas de qualquer shell simples — a receita está na documentação. Ou pule o MCP completamente e use o CLI (npx openpouch deploy, mesmas funções, --json + códigos de saída).

2. Deixe o agente implantar

Apontar o Claude Code para qualquer pasta de aplicativo e pedir para implantar. Nos bastidores, ele chama uma ferramenta:

// openpouch_deploy  { "dir": "." }

Para um aplicativo full-stack (uma API por trás do frontend), adicione um caminho de saúde para que o agente prove que o backend está realmente ativo, não apenas a interface:

// openpouch_deploy  { "dir": ".", "healthPath": "/api/health" }

openpouch constrói o aplicativo na implantação (uma pasta de origem bruta Vite/React/Svelte ou um servidor Node com uma etapa de construção — nenhuma construção local necessária), inicia-o em um contêiner reforçado e verifica a saúde antes de te informar que está ao vivo.

3. O que vem de volta

O resultado é um JSON estruturado — exatamente o que um agente precisa para tomar uma decisão, além de uma linha em linguagem simples para o humano que o executa:

{
  "ok": true,
  "url": "https://your-app-x1y2z3.openpouch.sh",   // o link compartilhável
  "healthStatus": "healthy",
  "summary": "Seu aplicativo está ao vivo em https://…  — qualquer um com quem você compartilhar pode abri-lo imediatamente.",
  "nextCommands": { "verify": "…", "logs": "…", "inspect": "…" },
  "evidence": ["deploy.manifest.json", "deploy.evidence.json", "DEPLOYMENT.md", "…"]
}

Três coisas que vale a pena destacar:

• A URL ao vivo é o resultado principal. Você a entrega diretamente a um cliente — sem configurações de construção, sem tour pelo painel.
• Um resumo em linguagem simples é seguro para relatar a um humano não técnico literalmente.
• A verdade da implantação chega como arquivos no repositório (DEPLOYMENT.md, deploy.evidence.json, …). Após um reset de contexto, um novo agente lê esses arquivos e sabe exatamente o que foi implantado, onde e como retomar. Sem estado oculto.

Se o aplicativo voltar não saudável, openpouch_logs mostra a saída de instalação/construção/aplicativo capturada (marcada como [install]/[build]/[app]) — o agente lê a causa, corrige, reimplanta, verifica. Um verdadeiro loop de auto-reparo.

Limites honestos (é uma prévia técnica)

• Pré-visualizações são efêmeras — elas desaparecem após ~72h, a menos que sejam reclamadas (reclamação → 7 dias). Ótimo para demonstrações, sites gerados por agentes e pré-visualizações para clientes; ainda não para produção de nível de pagamento.
• Variáveis de ambiente/secrets funcionam para aplicativos dinâmicos (--var / --env-file, injetadas em tempo de execução, relatadas apenas pelo nome), mas são efêmeras — ainda não há armazenamento persistente.
• É grátis durante a prévia. Hospedagem paga e persistente está no roadmap.
• Ele roda na infraestrutura própria do openpouch (não é um wrapper sobre o painel de outra pessoa), e o abuso é controlado com cotas e limites de taxa compatíveis com agentes — nunca um CAPTCHA, porque isso é exatamente o que quebra agentes.

Experimente

npx openpouch deploy

Código aberto, Apache-2.0: github.com/openpouch/openpouch · documentação (para você e seu agente): openpouch.dev

Se seu agente pode escrever software, ele deve ser capaz de enviá-lo. Essa é a ideia principal.