Claude Code agora pode colocar seu app no ar com Go Live

Autoria: Better Stack · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Claude Code Can Now Take Your App Live (GoLive) · Canal: Better Stack · 07:17 · Assistir no YouTube

Tópicos: Agentes de IA, Cibersegurança e segurança de software, Claude Code, Engenharia de software com IA

Resumo

Go Live é uma skill que ajuda agentes a preparar e publicar apps, coordenando serviços como hospedagem, banco de dados, email, DNS e Stripe. Em vez de agir automaticamente, ela apresenta um plano para aprovação, aplica as mudanças e verifica os resultados. O vídeo destaca limites importantes: ações que custam dinheiro são bloqueadas, e mudanças em produção exigem confirmação. Também aponta riscos e limitações, incluindo credenciais em texto simples, cobertura restrita e a necessidade de apagar alguns recursos manualmente.

Pontos-chave

Go Live detecta as necessidades do app e apresenta um plano com um ID antes de aplicar qualquer mudança.
Após aplicar o plano, verifica se as configurações funcionam, incluindo testes de assinatura de webhook do Stripe.
A skill usa credenciais que a pessoa já possui para serviços como Vercel, Supabase, Neon e Resend; Stripe é uma exceção.
Ações como aplicar um plano, excluir recursos, alterar DNS ou afetar produção exigem flags de confirmação.
A ferramenta recusa ações que custam dinheiro, como comprar um domínio, contratar um plano ou criar uma conta.
Ao desfazer mudanças, Go Live remove apenas recursos cuja criação consegue comprovar; projetos Supabase e Neon precisam ser apagados manualmente.
As flags de confirmação não provam que uma pessoa aprovou a ação e não impedem o agente de usar outras rotas.
A chave do Stripe é armazenada em texto simples, não criptografada nem guardada no keychain.
A cobertura ainda é limitada, e o projeto é apresentado como muito recente.

Capítulos

Início	Capítulo	Resumo
00:00	O problema de colocar um app no ar	O vídeo apresenta a complexidade de configurar hospedagem, banco de dados, DNS, email e pagamentos sem errar credenciais.
02:04	Demonstração do Go Live	O autor executa a skill no Claude Code, aprova um plano e mostra a aplicação e a verificação das mudanças.
03:08	Como funciona e quais são os limites	A ferramenta combina uma skill e uma CLI, usa contas já existentes e exige confirmações para ações sensíveis, além de recusar ações que custam dinheiro.
05:13	Riscos, cobertura e maturidade do projeto	O vídeo ressalta limitações das confirmações, o armazenamento da chave do Stripe, a remoção incompleta de recursos e a pouca maturidade do projeto.

Citações

Ele não trata a publicação como piloto automático. — 01:33

Qualquer coisa que custe dinheiro é recusada. — 03:40

Essas flags não são um bloqueio rígido. — 05:13

O desafio não é só torná-los capazes, mas fazer com que suas ações sejam compreensíveis, limitadas e reversíveis. — 07:17

Conceitos e entidades

Go Live (ferramenta): Skill e CLI que coordenam etapas de preparação e publicação de um app em serviços externos.
Claude Code (ferramenta): Ambiente de programação com agente usado no vídeo para executar Go Live.
Codex (ferramenta): Ferramenta indicada pelo autor como compatível e verificada com Go Live.
Vercel (empresa): Serviço usado no exemplo para hospedar o app.
Supabase (empresa): Serviço de banco de dados incluído no plano demonstrado.
Neon (empresa): Serviço de banco de dados citado entre os provedores suportados.
Resend (empresa): Serviço de email usado no exemplo de publicação.
Stripe (empresa): Serviço de pagamentos cujo webhook e modos de teste e produção são abordados.
Netlify (empresa): Serviço de hospedagem citado na comparação e na cobertura de adaptadores.
Terraform (ferramenta): Ferramenta de infraestrutura mencionada como opção mais abrangente que exige escrever e versionar código de infraestrutura.
SST (ferramenta): Ferramenta de infraestrutura comparada a Go Live por oferecer mais recursos, com necessidade de código de infraestrutura.
Better Stack (empresa): Canal que publicou o vídeo sobre Go Live.

Tradução completa (pt-BR)

00:00 Hoje em dia, nossos agents conseguem criar um app em 5 minutos. Aí tentamos colocá-lo no ar, e essa já é outra história. Este é o Go Live, uma skill de agent. Em vez de ficar alternando entre seis painéis, copiando API keys, editando registros de DNS e variáveis de ambiente, e tentando lembrar onde foi parar aquele segredo do webhook do Stripe, ele resolve praticamente tudo isso. Mas não é só o que essa skill consegue fazer; é também o que ela se recusa a fazer.

00:31 Certo, ótimo. Colocar um app no ar parece ser uma única etapa. Como a maioria de nós sabe, não é verdade, porque há muitas coisas envolvidas. Precisamos de hospedagem, um banco de dados, login, DNS em um domínio que seja nosso e um domínio de e-mail que precisa ser verificado, além de um webhook do Stripe com seu próprio segredo de assinatura. São muitas peças, e quase todos esses serviços fornecem credenciais que precisam acabar no lugar certo, tanto para a prévia quanto para a produção. O problema não é que alguma dessas etapas seja especialmente difícil; é que você precisa acertar

01:03 cada uma delas. E, para ser justo, é justamente aí que eu costumo dar errado. Não erro nas seis. Acerto cinco, aí uma coisinha dá errado e configuro tudo de forma incorreta. Talvez o segredo do webhook esteja errado, talvez o DNS do e-mail não esteja pronto, e eu não descubra isso durante o deploy. Pior: muitas vezes, só descobrem quando um cliente paga por algo e nunca recebe o recibo. É esse o problema que o Go Live tenta resolver: como juntar todas essas peças rapidamente. E a outra coisa legal aqui

01:33 é a maneira como ele resolve o problema. Ele não trata o deploy como se fosse no piloto automático. Trata-o mais como uma lista de verificação prévia que precisamos concluir primeiro. Ele detecta do que seu app precisa e, então, cria um plano de verdade. Você aprova exatamente esse plano e, depois, ele aplica as mudanças. Em seguida, verifica se essas mudanças realmente funcionam. Então, deixa eu mostrar. Se você gosta de ferramentas de programação que aceleram seu workflow, não deixe de se inscrever. Estamos sempre lançando vídeos. Este app já tem seu próprio código de checkout do Stripe.

02:04 Lembre-se disso, porque vai ser importante mais adiante. Estou no Claude Code. Vou executar /go-live e dizer: “Ajude-me a colocar este app no ar usando recursos de teste”. E veja o que acontece primeiro. Nada. Isso mesmo, nada. Ele não faz deploy de nada. O que está fazendo? Ele apresenta um plano: Vercel para hospedagem. Certo, Supabase para o banco de dados, Resend para e-mail e Stripe no modo de teste. E, então, atribui um ID a esse plano. Agora, eu aprovo

02:36 e o que ele vai fazer? Vai aplicar tudo. Mas a próxima parte é a que realmente me interessa. Ele verifica os resultados. Para o webhook, primeiro envia uma solicitação sem assinatura e garante que ela seja rejeitada. Depois, verifica se um evento de teste devidamente assinado é aceito. Então, faço um pagamento com o cartão de teste 4242, e o pagamento é aprovado. No fim, recebo uma URL ativa e um relatório escrito mostrando o que o Go Live criou, sem nenhum segredo dentro do relatório. Então, esse é um bom caminho.

03:08 Agora, vamos ver como ele faz isso. O Go Live é basicamente composto por duas partes. Há um arquivo de skill, que é o manual de instruções de que seu agent precisa. Depois, há uma pequena CLI em Node, que faz o trabalho de verdade. Isso não é um servidor MCP. Foi verificado no Claude Code e no Codex. Qualquer outro uso, segundo o autor, não foi verificado. Então: Claude Code e Codex. E há um detalhe importante aqui. O Go Live não cria um conjunto novo de credenciais para si. Ele usa os logins que você já tem para serviços como Vercel, Supabase, Neon e Resend.

03:40 O Stripe é a exceção. Há bloqueios por toda parte. Sem ID do plano, não há aplicação. Quer apagar algo? Isso exige uma flag confirm-destroy separada. Vai alterar o DNS? Confirme o DNS. Qualquer coisa na produção? Confirme a operação em produção. Mas essas flags de confirmação são apenas metade da história, porque o Go Live também tem coisas que simplesmente se recusa a fazer. Ele se recusa terminantemente a fazer qualquer coisa que custe dinheiro, o que é muito bom. Comprar algo, fazer upgrade de um plano ou criar uma conta nova: ele não apenas

04:11 avisa; a etapa simplesmente não é executada. Ele nunca vai comprar um domínio. Nunca vai comprar nada para você. Você ainda precisa providenciar essas coisas. E, quando você desfaz tudo ao terminar, o Go Live só apaga os recursos que consegue provar que criou. Ele não está tentando dar acesso ilimitado à sua infraestrutura a um agent. Está tentando automatizar a parte entediante sem fingir que toda ação deve ser automatizada. Agora, já existem várias ferramentas por aí. Isso é como uma skill, uma ferramenta nova. As integrações da Vercel e da Netlify funcionam muito bem se você ficar em uma única plataforma de hospedagem. O Terraform e o

04:43 SST conseguem fazer muito mais do que isso, mas você escreve e faz commit de código de infraestrutura. E, claro, agora temos os criadores de apps com IA, como Lovable, Bolt e v0, que fazem deploy na própria infraestrutura. O Go Live abrange muito menos recursos do que qualquer uma dessas opções. Em vez disso, oferece algo diferente: qualquer repo, suas contas e uma conversa, com um relatório escrito mostrando o que mudou. Mas, apesar de tudo isso, há algumas ressalvas que ainda preciso mencionar. Talvez sejam os documentos mais francos que já vi em um repo tão novo. Lembra de todas

05:13 aquelas flags de confirmação? O próprio documento de confiança do mantenedor aponta algo importante. Essas flags de “sim” e de confirmação são argumentos que o agent passa em seu nome. Não há nenhum registro de que uma pessoa de verdade tenha dito sim. E, se o agent já estiver conectado a um desses provedores, ele pode fazer alterações lá sem usar o Go Live. Então, eu não consideraria esses bloqueios uma trava rígida. Eles não impedem um agent de decidir seguir um caminho completamente diferente. Depois, há a questão da chave do Stripe. Ela fica em um arquivo de texto simples dentro da pasta de configuração do seu diretório pessoal. Esse

05:44 arquivo é restrito à sua conta de usuário, mas não fica no chaveiro e não é criptografado. As versões lançadas também não são assinadas criptograficamente. Há ainda outro problema com o Stripe que pode pegar você desprevenido. A prévia usa o modo de teste do Stripe por padrão. A produção usa o modo ativo por padrão. Então, se você ainda não tiver chaves ativas, precisa mudar a produção de volta para o modo de teste por conta própria. E a remoção não é uma restauração perfeita. O Go Live consegue remover o projeto da plataforma de hospedagem, os webhooks, as chaves de e-mail e os registros de DNS que marcou. Mas não consegue apagar projetos do Supabase ou do

06:16 Neon. Seu banco de dados continua lá. Você precisa apagá-lo manualmente. E, no teste do próprio criador, e-mails enviados de um subdomínio recém-criado podem até acabar na pasta de spam. Há também a questão da cobertura. No momento, apenas duas plataformas de hospedagem e dois bancos de dados têm adaptadores de verdade: Cell, Netlify, Supabase e Neon. Há mais uma coisa que vale saber antes de confiar a ele algo importante. Ainda é cedo demais. Com apenas um autor e 63 a 65 commits, o repo já está com

06:46 mais de mil estrelas em apenas alguns dias. Não posso dizer se isso é orgânico ou não. Também há um produto comercial de deploy chamado tofu, vinculado na página inicial do repo, enquanto o README diz que não existe uma conta do Go Live. Não consegui confirmar como essas duas coisas estão relacionadas, então ainda é muito cedo e eu levaria isso em conta. No último ano, a maioria das ferramentas de agent tem feito uma pergunta: o agent consegue fazer isso? O Go Live está levando a uma questão diferente: o que o agent deve ter permissão para fazer e, depois que faz

07:17 algo, como provar o que aconteceu? Porque, se os agents vão mexer em qualquer infraestrutura de verdade — e eles mexem bastante —, o problema difícil não é apenas torná-los capazes, mas fazer com que suas ações sejam compreensíveis, limitadas e reversíveis. Então, fica a pergunta: você deixaria um agent de IA mexer na sua conta do Stripe? Pode responder nos comentários. Se você gosta de dicas e truques de programação como este, não deixe de se inscrever no canal Better Stack. A gente se vê em outro vídeo.

Transcrição original

[00:00] Nowadays, our agents can build an app in 5 minutes. Then we try to put it online, and that’s a whole different story. This is Go Live, an agent skill. Instead of bouncing between six dashboards, copying API keys, editing DNS records, your environment variables, and trying to remember where that Stripe webhook secret went, this fixes practically all that. But, it’s not only what this skill can do, it’s also what it refuses to do.

[00:31] Okay, great. Now, going live sounds like one step. As most of us know, that’s not true because a lot of things are at play. We need hosting, a database, you need sign-on DNS on a domain that we own, and an email domain that has to be verified, a Stripe webhook with its own signing secret. That’s a lot of pieces here, and almost all of those services hand you credentials that you need to end up in the right place for both preview and production. The problem isn’t that any one of those steps is especially hard, is that you have to get

[01:03] every single one right. And to be fair, that’s honestly where I usually break things. I don’t mess up all six. I get five right, then one tiny thing is botched, and I wired it up all wrong. Maybe the webhook secret is wrong, maybe the email DNS isn’t finished, and I don’t discover that while actually deploying. Heck, often it gets discovered when a customer pays for something and never gets a receipt. That’s the problem Go Live is trying to solve. How all these pieces go together, in fast. And the other cool thing here

[01:33] is how it actually solves it. It doesn’t treat deployment like autopilot. It treats it more like this preflight checklist that we have to get through first. It detects what your app needs, then it writes an actual plan. You approve that exact plan, then it applies the changes. And after that, it checks whether those changes actually work. So, let me show you. If you enjoy coding tools that speed up your workflow, be sure to subscribe. We have videos coming out all the time. Now, this app already has its own Stripe checkout code.

[02:04] Remember that because it becomes important later. I’m in Claude code. I’m just going to run {slash} go live, and we’re going to tell it here, “Help me take this app live use test resources.” And watch what happens first. Nothing. Yeah, nothing. It doesn’t deploy anything. What is it doing? It gives you a plan Vercel for hosting. Okay, Supabase for the database, Resend for email, Stripe in test mode. And then it gives that plan an ID. Now, I approve

[02:36] it, and what’s it going to do? It’s going to apply everything. But this next part is what I actually care about. It verifies the results. For the webhook, it sends an unsigned request first and makes sure that request gets rejected. Then it checks that a properly signed test event makes it through. So, I run a payment with a test card 4242, payment clears. And at the end, I got a live URL plus a written report showing what go live created, but no secrets inside that report. So, that’s just a good path.

[03:08] Now, let’s look at how it’s actually doing this. Go live is basically two pieces. There’s a skill file, which is the instruction manual your agent needs. Then there’s a small node CLI, which does the actual work. This isn’t an MCP server. It’s verified on Claude code and Codex. Anything else, according to the author, is unverified. So, Claude code Codex. Then there’s the important detail here. Go live doesn’t create a fresh set of credentials for itself. It borrows the logins you already have for things like Vercel, Supabase, Neon, Resend.

[03:40] Stripe is the exception. There are gates everywhere. No plan ID, no apply. Want to delete something? That’s a separate confirm destroy flag. Changing DNS? Confirm DNS. Anything live on production, confirm live. But those confirmation flags are only half of all this because go live also has things in it that it simply refuses to do. Anything that costs money it refuses outright, which is really nice. Buying something, upgrading a plan, or signing up for a new account, it doesn’t just

[04:11] warn you, that step just doesn’t actually run. It will never buy a domain. It will never buy anything for you. You have to still bring your own. And when you tear everything back down when you’re done, go live only deletes resources it can prove it created. This isn’t trying to give an agent unlimited access to your infrastructure. It’s trying to automate the boring part without pretending that every action should be automated. Now, we already have a bunch of tools out here. This is like a skill, it’s a new tool. Vercel and Netlify integrations work great if you stay inside one host. Terraform and

[04:43] SST can do far more than this, but you’re writing and committing infrastructure code. Then, of course, we’ve got your AI app builders now, lovable bold v0, which deploy onto their own infrastructure. Go live covers far fewer resources than any of those. What it’s offering instead is different. Any repo, your accounts, one conversation in a written report showing what it changed. But with all this, there are a few caveats that I should still hit on. These might be the most candid docs I’ve seen on a repo this new. Remember all

[05:13] those confirmation flags? The maintainer’s own trust document points out something important. Those yes and confirmation flags are arguments the agent passes you on behalf. Nothing records that an actual human said yes to. And if your agent is already logged into one of those providers, it can write there without using go live at all. So, I wouldn’t think of these gates as like a hard lock. They don’t stop an agent from deciding to take a completely different route. Then, there’s the whole Stripe key. It sits in a plain text file inside your home config folder. That

[05:44] file is locked to your user account, but it isn’t in the keychain and it isn’t encrypted. The releases also aren’t cryptographically signed. Then there’s another stripe issue that could easily catch you. Preview defaults to stripe test mode. Production defaults to live mode. So if you don’t have live keys yet, you have to switch production back and test yourself. And the teardown isn’t a perfect reset either. Go live can remove the host project webhooks email keys and the DNS records it tagged. But it can’t delete Supabase or

[06:16] Neon projects. Your database stays behind. You have to delete that manually. And in the creator’s own test run, email from a brand new subdomain might even land in spam. Then there’s the whole coverage. Right now only two hosts and two databases have real adapters for Cell, Netlify, Supabase, and Neon. There’s one final thing here worth knowing before you trust this with anything important. This is way too early. With just one author and 63-65 commits and somehow the repo’s already

[06:46] sitting at over a thousand stars in just a few days. I can’t tell you whether that is organic or not. There’s also a commercial deploy product called tofu linked from the repo’s homepage while the readme says there is no go live account. I couldn’t confirm how those two are connected, so this is very early stuff and I would treat it that way. For the last year most agent tools have been asking one question. Can the agent do it? Go live is resulting to something different. What should the agent be allowed to do and after it does

[07:17] something, how do you prove what happened? Because if agents are going to touch any real infrastructure, which they do a lot, the hard problem isn’t just making them capable, it’s making their actions understandable, limited, and reversible. So here’s the question. Would you let an AI agent touch your Stripe account? You can drop it in the comments. If you enjoy coding tips and tricks like this, be sure to subscribe to the Better Stack channel. We’ll see you in another video.