Até aqui a automação rodava na sua máquina, quando você mandava. Para ela rodar sozinha na internet, três peças se combinam: o código mora no GitHub, o Trigger.dev executa, e o gatilho é uma agenda (cron) ou um evento (webhook). O diagrama mostra como elas se ligam.
Diagrama ilustrativo — recriação conceitual da infraestrutura de deploy, não uma captura de tela real.
☁️ Automações hospedadas
O que é
Uma automação hospedada é um script que roda na internet por conta própria — sem você abrir nada nem clicar em "executar". Em vez de a automação viver na sua máquina e depender de você estar presente, ela passa a viver na nuvem e dispara sozinha: por agenda (cron) ou por evento (webhook). É a passagem de "rodar quando eu mando" para "rodar sozinho".
Por que aprender
A grande limitação da automação disparada por humano é simples: ela só escala na velocidade em que uma pessoa consegue aparecer e clicar. Se a tarefa precisa rodar toda manhã às 7h, ou no instante em que um formulário é enviado, depender de você é um gargalo. Hospedar elimina esse gargalo.
- •Roda sem supervisão: a tarefa acontece mesmo com você dormindo ou de férias.
- •Escala de verdade: a frequência deixa de depender da sua disponibilidade.
- •Confiabilidade: com retries e logs, falhas são tratadas e ficam visíveis.
Conceitos-chave
✓ O que muda ao hospedar
- ✓O código sai da máquina e vai para a nuvem.
- ✓O gatilho passa a ser agenda ou evento, não um clique.
- ✓Um motor (Trigger.dev) cuida de execução, retries e logs.
✗ O que NÃO é hospedar
- ✗Deixar o computador ligado com o editor aberto a noite toda.
- ✗Rodar a tarefa manualmente "quando lembro".
- ✗Depender de você para clicar antes que algo aconteça.
🎯 Dica prática
Dois builds ancoram esta trilha: um agente de pesquisa agendado (cron, toda manhã) e um gerador de relatório por webhook (disparado por evento). Tê-los em mente ajuda a entender por que cada peça de infraestrutura existe.
🕳️ O "agentic gap"
O que é
Numa sessão interativa, a IA observa cada erro, diagnostica e corrige — o famoso loop de auto-cura. Quando a tarefa passa a rodar sozinha na nuvem, esse loop desaparece: a IA não está mais ali olhando. O agentic gap é essa lacuna — o sistema executa, mas não se adapta sozinho, e uma falha pode passar despercebida tanto pela IA quanto por você.
Por que aprender
✓ Como fechar a lacuna
- ✓Retries automáticos com termos configuráveis.
- ✓Traces completos de cada passo da execução.
- ✓Alertas de falha (e-mail/Slack) e sem timeout.
✗ O que deixa de existir
- ✗A IA lendo o erro e consertando na hora.
- ✗Adaptação espontânea a um cenário novo.
- ✗Garantia de que alguém vai notar a quebra.
Conceitos-chave
Como a IA não vai se auto-curar em produção, builds não-supervisionados pedem quatro coisas desde o primeiro prompt: entradas fixas, saídas estruturadas e previsíveis, tratamento de erro embutido e log em cada passo. As palavras-chave "roda sozinho" e "toda manhã" sinalizam para a IA projetar para uma agenda, sem humano no loop.
Sem perguntas no meio.
Formato previsível.
Tratamento desde o início.
Visibilidade total.
⏰ Cron
O que é
O cron é um padrão de temporização de cinco campos que diz quando uma tarefa deve disparar. Os campos, na ordem, são: minuto, hora, dia-do-mês, mês e dia-da-semana. Um asterisco (*) significa "qualquer valor". O clássico 0 7 * * * lê-se como "no minuto 0 da hora 7, todo dia, todo mês, todo dia da semana" — ou seja, 7h da manhã, todos os dias.
# ┌───────── minuto (0-59) # │ ┌─────── hora (0-23) # │ │ ┌───── dia do mês (1-31) # │ │ │ ┌─── mês (1-12) # │ │ │ │ ┌─ dia da semana (0-6) # │ │ │ │ │ 0 7 * * * # 7h todo dia 0 8 * * 1 # 8h toda segunda */15 * * * * # a cada 15 minutos
Por que aprender
Cron é a linguagem universal de agendamento — ela aparece no Trigger.dev e em praticamente toda plataforma de automação. Saber ler e escrever esses cinco campos coloca você no controle de quando a tarefa dispara, sem depender de adivinhação ou de uma interface gráfica limitada.
🎯 Dica prática
Você não precisa decorar a sintaxe: descreva o horário em linguagem natural ("toda manhã às 7h") e deixe a IA gerar a expressão cron. Mas reconhecer os cinco campos ajuda a conferir se o que ela gerou bate com o que você quis.
Min, hora, dia, mês, dia-sem.
Curinga em cada posição.
Dispara em ciclo.
7h todo dia.
🗄️ GitHub como armazenamento de código
O que é
O GitHub é armazenamento de código na nuvem. Em vez de o código viver só na sua máquina, ele mora num repositório (a pasta do projeto dentro do GitHub) — acessível de qualquer computador, com histórico completo de versões para rollback e troubleshooting. As plataformas de deploy, como o Trigger.dev, puxam o código diretamente de lá.
Por que aprender
Para uma automação rodar na nuvem, o código precisa existir num lugar que a nuvem alcance. O GitHub é esse lugar — a fonte única do que vai para produção. De quebra, o histórico de commits permite voltar a uma versão que funcionava quando algo dá errado.
- •Acesso de qualquer lugar: o código não fica preso a um dispositivo.
- •Histórico + rollback: cada commit é um ponto de restauração.
- •Integração de deploy: o Trigger.dev puxa direto do repositório.
Conceitos-chave
Vocabulário de Git
Repositório (repo)
A pasta do projeto dentro do GitHub, que guarda todos os commits. Crie-o privado e inicialize com um README.
Commit
Um snapshot salvo do código, com uma descrição das mudanças. É o seu ponto de restauração no histórico.
Push
O ato de enviar os commits da sua máquina para o GitHub. O assistente conecta a pasta local ao repo e faz o primeiro commit por você.
🎯 Dica prática
Prefira um caminho local limpo (ex.: Documentos) e evite colocar o projeto dentro de uma pasta sincronizada com a nuvem. Você verá vários pedidos de permissão para comandos bash — aprová-los é normal, não é erro.
🔒 gh CLI & .gitignore
O que é
O gh (GitHub CLI) é a ferramenta de linha de comando que autentica e conecta o projeto local ao GitHub. O .gitignore é um arquivo que lista o que nunca deve subir para o repositório. Juntos, eles deixam você empurrar o código com segurança — e mantêm os segredos fora da nuvem pública.
Por que aprender
⚠️ A regra de ouro: o .env nunca sobe
O arquivo .env guarda as chaves de API. Se ele for parar num repositório (mesmo privado), suas chaves ficam expostas. O assistente adiciona o .env ao .gitignore automaticamente — mas confira.
- ✗Nunca commitar o
.env— o ponto inicial ajuda, mas confie no.gitignore. - ✗Nunca colar chaves de API no chat.
- ✗Não assumir que "repo privado" = seguro para segredos.
Conceitos-chave
Instalando e autenticando o gh
Pré-requisito do gerenciador de pacotes
No macOS, instale o Homebrew primeiro; no Windows, o WinGet. Depois, brew install gh (ou o equivalente).
Autenticar com gh auth login
Escolha GitHub.com, HTTPS, autenticação via navegador; cole o código de uso único e autorize.
Conectar e verificar
O assistente conecta a pasta local ao repo, puxa o README, escreve o .gitignore e confirma a sincronização.
🎯 Dica prática
Escolha um nome de usuário público profissional — ele aparece no perfil. E lembre: os repetidos pedidos de permissão para comandos bash durante a conexão são esperados; leia junto para entender cada passo.
🚀 Trigger.dev
O que é
O Trigger.dev é o motor de execução na nuvem — como um assistente firme e confiável, não um lembrete colado na geladeira. Ele roda as tarefas sem timeouts (tempo o quanto for preciso), com retries automáticos, traces completos de cada passo, suporte a agendas e webhooks, e alertas de falha. Ele roda em TypeScript — mas a IA escreve o TypeScript, então a abordagem de vibe coding não muda.
Por que aprender
✓ O que o Trigger.dev entrega
- ✓Sem timeout: tarefas longas rodam até terminar.
- ✓Retries automáticos para falhas transitórias.
- ✓Traces + alertas + MCP oficial para a IA gerenciar.
📊 Por que TypeScript não é problema
- •A IA gera todo o código TypeScript a partir da conversa.
- •Você continua descrevendo o resultado, não escrevendo código.
- •O fluxo de prompting é exatamente o mesmo das fases anteriores.
Conceitos-chave
A divisão de responsabilidade é clara: o GitHub armazena o código; o Trigger.dev executa — agendamento, webhooks, retries, logging e alertas. O dashboard do Trigger.dev é a sua janela para o que acontece em produção, o que ajuda justamente a fechar o agentic gap, já que a IA não está mais observando os erros.
Roda o tempo que precisar.
Tenta de novo sozinho.
Cada passo registrado.
Janela da produção.
🧰 Inicializar projeto + MCP do Trigger.dev
O que é
Inicializar o projeto significa instalar o MCP oficial do Trigger.dev (que deixa a IA gerenciar o projeto por conversa), rodar o init (cria o trigger.config.ts e a pasta de tasks) e subir o worker de dev para que as tarefas se registrem e executem. A conta do Trigger.dev se cria com o GitHub, e o projeto recebe o mesmo nome do repositório.
Por que aprender
A sequência de inicialização
Instalar o MCP e reiniciar
Peça à IA para instalar o MCP do Trigger.dev; aprove os comandos. Reinicie o assistente depois — senão o server pode não aparecer (causa comum de erro).
Copiar o Project ID e rodar o init
Pegue o Project ID em Project Settings > General. O init é interativo e pode precisar rodar no terminal; escolha o exemplo "hello world".
Subir o worker de dev e confirmar
Rode o worker de dev para registrar a task; confirme que o "hello world" aparece no dashboard. Peça à IA para dispará-la e veja run, traces, payload e output.
Conceitos-chave
✓ Anatomia do dashboard
- ✓Task view, lista de Runs e traces por execução.
- ✓Timeline, painéis de payload e output.
- ✓Seções de Schedules, Queues e Alerts.
✗ Armadilhas comuns
- ✗Esquecer de reiniciar após instalar o MCP.
- ✗Esperar o init não-interativo (às vezes precisa do terminal).
- ✗Confundir ambiente de dev com produção ao testar.
🎯 Dica prática
Sempre abra a pasta do projeto no editor para que a IA possa gerenciá-lo por conversa em vez de cair no terminal. Construa e teste em dev; só promova para produção quando estiver pronto para ir ao ar.
🗝️ Secrets management
O que é
Chaves e segredos nunca podem viver no código público — e o Trigger.dev não consegue ler o .env local. A solução é guardar os secrets no dashboard de Environment Variables do Trigger.dev: eles ficam fora do código e são injetados em runtime, só quando a tarefa roda. Localmente, você mantém um .env (git-ignorado) para desenvolvimento.
Por que aprender
Sem os secrets na nuvem, a tarefa funciona localmente mas quebra em produção — porque lá ela não tem acesso ao seu .env. O assistente cria o .env, garante que ele está no .gitignore, gera um .env.example seguro de versionar e atualiza o código para ler de process.env.
- •Local:
.envna máquina, para desenvolver. - •Nuvem: Environment Variables do Trigger.dev, injetadas em runtime.
- •Versionável: só o
.env.example(sem valores reais) sobe ao repo.
Conceitos-chave
⚠️ As três regras de ouro
- ✗Nunca colar chaves de API no chat do assistente.
- ✗Nunca commitar o
.envno GitHub. - ✗Não esquecer de adicionar a variável também no ambiente de produção, não só no de dev.
🎯 Dica prática
Ao adicionar cada chave (ex.: Anthropic, Firecrawl, Google Sheets via OAuth), marque dev E prod — esquecer o ambiente de produção é um dos motivos mais comuns de a tarefa funcionar no teste e falhar quando vai ao ar. Considere rotacionar chaves e usar chaves distintas para local e produção.
Auto-recuperação (opcional): a tarefa funciona no teste local, mas falha em produção dizendo que uma chave de API está faltando. Onde provavelmente está o problema?
📌 Resumo do Módulo
0 7 * * * = 7h todo dia.Próximo Módulo:
3.2 — Agentes em Produção: Agendados & Webhooks