🐙 GitHub MCP + token + Docker
Para publicar sem sair do editor, conecte o AntiGravity ao GitHub via MCP: assim você gerencia e publica repositórios direto dali. A integração exige duas coisas: um Personal Access Token (fine-grained, com validade) e o Docker instalado.
✓ Pré-requisitos
- ✓Personal Access Token fine-grained
- ✓Definir uma validade para o token
- ✓Docker instalado e rodando
✗ Erros comuns
- ✗Token sem validade ou com escopo amplo demais
- ✗Esquecer de abrir o Docker antes
- ✗Colar o token no código (use o lugar certo)
do editor
fine-grained
com expiração
instalado
▲ Deploy na Vercel
A Vercel é a "ponte" do GitHub para o mundo: ela hospeda seu app em produção. O fluxo é curto e visual: Add New → Project → importar o repo → publicar. Em poucos cliques, o app fica no ar com um link público.
Add New → Project
No painel da Vercel, comece um novo projeto.
Importar o repo
Conecte sua conta do GitHub e selecione o repositório do app.
Publicar
A Vercel faz o build e sobe o app. Pronto: ele está no ar para o mundo.
💡 Localhost × produção
No localhost, só você vê. Em produção (Vercel), qualquer pessoa com o link acessa. É o salto de "funciona na minha máquina" para "está no ar".
GitHub → mundo
o repo
link público
poucos cliques
🔐 Environment variables
Chaves de API nunca devem aparecer no código. A regra de ouro: o agente apenas nomeia a variável; você cola a chave dentro da Vercel (Settings → Environment Variables) e dá Redeploy.
✓ Jeito seguro
- ✓O agente só nomeia:
API_KEY - ✓Você cola o valor na Vercel
- ✓Redeploy para a chave entrar em vigor
✗ Nunca faça
- ✗Colar a chave dentro do código
- ✗Subir a chave para um repo público
- ✗Mandar a chave em prints ou chats
| Parte | Quem cuida | Onde vive |
|---|---|---|
| Nome da variável | o agente | no código (só o nome) |
| Valor da chave | você | Vercel → Settings → Env Vars |
| Ativar mudança | você | Redeploy |
o agente
você, na Vercel
ativa a chave
no código
📊 Analytics & Speed Insights
Depois de no ar, você quer saber se as pessoas usam — e se o app é rápido. A Vercel oferece Analytics (acessos) e Speed Insights (performance). Habilite no painel e instale o pacote pelo terminal (npm). O plano grátis é generoso.
npm i @vercel/analytics @vercel/speed-insights
📈 Analytics
Quantos acessos, de onde vêm, quais páginas. Mostra se o app está sendo usado de verdade.
⚡ Speed Insights
Mede a performance real sentida pelos usuários. App lento espanta gente — aqui você vê onde melhorar.
💡 Decisão por dados
Sem dados, você adivinha o que melhorar. Com Analytics e Speed Insights, você foca no que realmente afeta seus usuários.
no painel
instala o pacote
+ performance
plano generoso
🩺 Troubleshooting por screenshot
Quando um build falha, não entre em pânico nem tente decifrar o erro sozinho. Tire um screenshot dos logs de erro e mande pro agente: "houve um erro no deploy, corrija". Para erros na tela, use o DevTools (Console/Network) e mande o print.
Capture o erro
Screenshot dos logs de build na Vercel, ou do Console/Network no DevTools.
Mande pro agente
"Houve um erro no deploy (veja o print). Corrija." A imagem dá o contexto exato.
Ele corrige e você re-publica
Com o erro à vista, o agente acerta a correção muito mais rápido.
🔎 DevTools é seu amigo
O Console mostra erros de código; a aba Network mostra requisições que falharam. Um print dessas telas vale mais que mil descrições.
dos logs
com o print
Console/Network
a imagem ajuda
💾 Commit often
Uma lição que dói aprender na prática: comite com frequência. História real — codar 6 horas sem commitar e perder justamente a melhor versão num passo em falso. O controle de versão é a sua rede de segurança.
✓ Comite sempre
- ✓A cada pequeno avanço que funciona
- ✓Mensagens curtas e claras
- ✓Cada commit = um ponto de retorno seguro
✗ O risco de não commitar
- ✗Horas de trabalho num único bloco frágil
- ✗Um erro apaga a melhor versão
- ✗Sem ponto de retorno, você recomeça
⚓ Pontos de retorno
Pense em cada commit como um "save" do jogo. Se algo der errado, você volta ao último save — e nunca perde mais do que o último pedaço.
cada avanço
linha do tempo
ponto de retorno
de segurança
⏪ Rollback
Um deploy ruim não é o fim do mundo — é só um rollback. Na Vercel: Deployments → escolha a versão anterior estável → Redeploy. É literalmente "voltar no tempo". Também dá para reverter pelo GitHub.
| Por onde | Passo | Resultado |
|---|---|---|
| Vercel | Deployments → versão estável → Redeploy | volta no tempo |
| GitHub | reverter para o commit bom | desfaz a mudança |
o histórico
a versão boa
volta no tempo
também reverte
💰 Budget de API + repo privado
Dois cuidados finais para dormir tranquilo. Primeiro: defina um budget de gasto na API para não tomar uma conta gigante. Segundo: torne o repositório privado depois de publicado, protegendo seu código.
💰 Budget de API
Defina um teto de gasto no painel do provedor da API.
- •Evita sustos na fatura
- •Protege contra loops ou abuso
🔒 Repo privado
Depois de publicar, mude a visibilidade do repositório para privado.
- •Protege seu código
- •Reduz risco de chaves vazadas
🛡️ Higiene de produção
Budget de API + repo privado + env vars formam a base da segurança do seu app no ar. São hábitos simples que evitam dores de cabeça caras.
teto de gasto
na fatura
após publicar
código + chaves
🔬 Exemplo prático
Vamos publicar o rastreador de preços da Trilha 2.1 e mantê-lo vivo:
- Publique na Vercel — Add New → Project → importar o repo → publicar.
- Proteja a chave — o agente nomeia
API_KEY; você cola o valor em Settings → Environment Variables e dá Redeploy. - Simule um deploy ruim — depois faça um rollback: Deployments → versão estável → Redeploy.
Resultado: app no ar, chave segura, e a tranquilidade de saber que dá pra voltar no tempo.
🏋️ Exercício
Leve o app que você construiu na 2.1 até o mundo:
- Publique seu app na Vercel e confirme que o link funciona.
- Proteja uma chave por env var — nomeie no código, cole o valor na Vercel, Redeploy.
- Faça um rollback para a versão anterior e veja o app "voltar no tempo".
Bônus: ligue Analytics e defina um budget de API. Na Trilha 3, você vai escalar a produção.
⚡ Prompts prontos
Copie, cole no seu assistente de IA e adapte ao seu caso.
Crie um repositório no GitHub chamado [nome] e publique o projeto atual. Use o GitHub MCP. Não inclua chaves de API no código.
Especifique como a variável de ambiente deve se chamar (ex.: API_KEY); eu forneço a chave dentro da Vercel. Não coloque o valor no código.
Houve um erro no deploy (veja o print). Corrija. Explique em uma frase o que causou e o que você mudou.
✅ Resumo do módulo
Próxima trilha:
Trilha 3 — Escalar a Produção