🌐 Por que local não basta

Até aqui você fez seu agente de código responder a pedidos: você abre o terminal (a caixa de texto que dá ordens direto ao computador), digita o que quer, ele executa, você vê o resultado. Isso funciona muito bem — mas tem uma condição escondida: você precisa estar lá. Computador ligado, aplicativo aberto, você presente pra apertar Enter.

Pense numa tarefa "pendurada": é aquele lembrete que fica esperando alguém chegar pra executar. Você escreveu um post-it "ligar pro fornecedor às 9h" e colou na tela — mas o post-it não liga sozinho. Ele só existe até você chegar, ver, e agir. Uma automação que só roda no seu terminal é exatamente isso: um post-it sofisticado. Sofisticado porque, quando você chega e aperta o botão, ela faz o trabalho inteiro sozinha. Mas ainda depende de alguém chegar.

Isso muda tudo na prática: se a automação deveria rodar todo dia às 7h da manhã, mas seu laptop estava desligado (ou fechado, ou sem internet, ou você estava de férias), ela simplesmente não rodou. Ninguém avisa. Não existe um "ela tentou e falhou" — existe um silêncio total, porque nada foi disparado.

Agora troque a imagem do post-it pela de um funcionário de verdade. Um funcionário presencial só trabalha quando está no escritório, junto com você — se você fecha o escritório, ele para. Um funcionário remoto, contratado e instalado em outro lugar, continua trabalhando mesmo que o SEU prédio esteja fechado. Ele tem o próprio espaço, as próprias chaves, e cumpre o horário combinado independente de onde você esteja.

Novo aqui? Nuvem (cloud) é o nome comum pra "computador de outra empresa que você aluga pela internet, ligado 24 horas por dia, em um data center, que nunca desliga porque você fechou o notebook". Quando dizemos que uma automação "roda na nuvem", queremos dizer que o código dela está executando numa dessas máquinas remotas — não na sua.

Novo aqui? Código é o conjunto de instruções escritas que dizem ao computador exatamente o que fazer, passo a passo — é o que o seu agente escreve quando você pede pra automatizar algo. Quando esse código roda local, ele fica só na memória do seu computador, do jeito que um bilhete só existe na sua mesa. Pra ele existir "em outro lugar" e ficar sempre disponível, ele precisa ser levado pra lá.

Legenda: o mesmo código, dois destinos diferentes. Do lado esquerdo ele depende do seu laptop ligado; do lado direito ele mora num servidor que nunca desliga e registra tudo o que faz.

Sair do local pra nuvem não é um passo só — é uma sequência de estações, cada uma entregando o trabalho pra próxima. O Módulo 4.2 detalha cada estação a fundo; aqui você já vê o caminho inteiro, pra entender por que ele existe.

Antes de qualquer coisa ir pra nuvem, vale sentir na pele o que "rodar local" significa: você dispara o comando, o processo executa enquanto o terminal (a janela de comandos) está aberto, e some quando você fecha. Nenhuma mágica — é exatamente isso que os módulos 4.2 a 4.6 vão substituir por algo que continua rodando sem você.

Objetivo: rodar um script (um arquivo de instruções simples) local no seu terminal e observar que ele só existe enquanto você o mantém aberto.

cd minha-automacao
node verificar-estoque.js

# saída esperada no terminal:
# [12:04:02] Verificando estoque...
# [12:04:03] 3 produtos abaixo do mínimo. E-mail simulado enviado.
# [12:04:03] Processo encerrado.

Como verificar: feche o terminal (ou desligue o wi-fi, ou desligue o notebook) e espere o horário em que essa automação "deveria" rodar de novo amanhã de manhã. Ela não vai rodar — porque não existe nada além do seu comando manual mantendo-a viva. É essa lacuna exata que uma variável de ambiente (uma "chave secreta" configurada num servidor, como SUA_CHAVE_AQUI, coberta em detalhe no módulo 4.4) e uma plataforma como o Trigger.dev vêm resolver: o mesmo código passa a rodar sozinho, num servidor que nunca fecha o terminal.

A Trilha 4 inteira existe pra atravessar essa ponte: código no seu computador → repositório → plataforma de execução na nuvem. Você não vai virar programador — o agente escreve o TypeScript, você lê, aprova e acompanha pelo painel. Mas você precisa entender essa ponte pra confiar no resultado e saber onde olhar quando algo falhar.