📌 The dangling task
So far, you’ve had your coding agent respond to requests: you open the terminal (the text box that gives commands directly to the computer), type what you want, and it runs it—you see the result. This works very well—but it has a hidden condition: you need to be there. Computer on, application open, you there to press Enter.
Think of a task that’s “hanging around”: it’s a reminder waiting for someone to show up and do it. You wrote a sticky note saying “call the supplier at 9” and stuck it on your screen—but the note can’t make the call by itself. It just sits there until you show up, see it, and act. An automation that only runs in your terminal is exactly that: a sophisticated sticky note. Sophisticated because when you show up and press the button, it does the entire job on its own. But it still depends on someone showing up.
This completely changes things in practice: if the automation is supposed to run every day at 7 a.m., but your laptop was turned off (or closed, or without internet, or you were on vacation), it simply didn't run. No one lets you know. There is no "it tried and failed"—there is complete silence because nothing was triggered.
💡 Main Concept
"Run locally" means the code only runs while your computer is on and the program is open — execution depends physically on your machine. That's great for testing and learning (it's what you did in tracks 1, 2, and 3), but it's far too fragile to trust with real work.
- •Local = depends on you being present and your computer being on.
- •Real automation = runs on its own, at the right time, even when you’re asleep, traveling, or carrying your laptop in your backpack.
🌙 The employee who works while you sleep
Now replace the sticky-note image with that of a real employee. An on-site employee only works when they’re in the office with you—if you close the office, they stop. A remote employee, hired and set up somewhere else, keeps working even when YOUR building is closed. They have their own space, their own keys, and work the agreed-upon hours regardless of where you are.
New here? Cloud (cloud) is the common term for "a computer owned by another company that you rent over the internet, running 24 hours a day in a data center, and never shuts down just because you closed your laptop." When we say an automation "runs in the cloud," we mean its code is running on one of these remote machines — not on yours.
✗ Running locally (your terminal)
- ✗Only runs if your computer is on and you’re there
- ✗You closed your laptop and traveled without internet: the automation simply won't run
- ✗No warning that it “should” have run but didn’t
✓ Running 24/7 in the cloud
- ✓Runs at the scheduled time, while you’re asleep, offline, or in another country
- ✓The computer running it isn’t yours—it’s a remote server you pay to use
- ✓Generates a log (more in topic 3) showing what happened, even if you don’t check it right away
⚠️ Attention
"Run in the cloud" isn't magic, and it isn't inherently expensive — it simply means publishing the same code you've already tested locally in a place that stays on all the time. Module 4.2 shows exactly how to do this technically, step by step.
🔍 Under the hood: what changes technically
New here? Code is the set of written instructions that tell the computer exactly what to do, step by step — it's what your agent writes when you ask it to automate something. When this code runs locally, it stays only in your computer's memory, like a note that exists only on your desk. For it to exist "somewhere else" and always be available, it needs to be taken there.
Caption: same code, two different destinations. On the left, it depends on your laptop being on; on the right, it lives on a server that never shuts down and records everything it does.
🔍 Inside
- Repository: a special folder (usually on GitHub) where the code is stored along with a history of all changes — that’s where the cloud “pulls” the code from to run it. Covered in depth in module 4.2.
- Production environment: the technical name for the place (a cloud server) where the “real” version of the automation runs, serving you or other people for real — unlike your terminal, which is the test environment (covered in more depth in module 4.3).
- Log: the list of events the automation recorded while it was running — it’s how you “see” what happened when you weren’t there to watch live.
🚀 The path from code to cloud, in order
Moving from local to the cloud isn’t a single step — it’s a series of stations, each handing the work off to the next. Module 4.2 covers each station in depth; here you can already see the whole path and understand why it exists.
The agent writes the code
You don’t have to write this by hand. You describe what you want, and the agent writes it in TypeScript (the programming language used in this track — just a standardized way to write instructions for the computer), and you read and approve it before continuing.
The code goes into the repository
Using git (the tool that keeps a version history of your code, like a "save" with a memory of everything that has changed), the code is sent to a stored copy on GitHub — the repository.
The execution platform pulls and runs
A cloud service (we’ll use Trigger.dev in this track) fetches this code from the repository and keeps it running 24 hours a day — this is called deploy: publishing the code somewhere it runs on its own.
You monitor it through the dashboard
Without needing to know how to read TypeScript: you check the execution log to see whether it ran, when it ran, and whether it succeeded. That’s the focus of module 4.7.
💡 Main Concept
We call this sequence pipeline — an assembly line where each station handles part of the work and passes it to the next. You take part at both ends (requesting and approving the code, reading the dashboard) — the middle is automatic.
🖥️ Feel the difference in practice: run it locally once
Before anything goes to the cloud, it helps to experience firsthand what “running locally” means: you run the command, the process runs while the terminal (the command window) is open, and disappears when you close it. No magic—that’s exactly what modules 4.2 through 4.6 will replace with something that keeps running without you.
Objective: run a script (a simple instruction file) locally in your terminal and see that it only exists while you keep it open.
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.
How to verify: close the terminal (or turn off wi-fi, or
shut down the laptop) and wait until the time this automation is "supposed" to run again tomorrow morning.
It won't run — because nothing beyond your manual command is keeping it alive. That's the exact gap
an environment variable (a "secret key" configured on a server, such as
SUA_CHAVE_AQUI, covered in detail
in module 4.4) and a platform like Trigger.dev come in: the same code starts running
on its own, on a server that never closes the terminal.
✗ What you just did (local)
- ✗Ran it once, right then, because you told it to
- ✗If you close the terminal, the process dies too
✓ What module 4.6 will build
- ✓The same published script, running on its own every day at the scheduled time
- ✓Keeps running even when your terminal has been closed for weeks
🗺️ Consolidating the mental model
The entire Track 4 exists to cross this bridge: code on your computer → repository → cloud execution platform. You won’t become a programmer—the agent writes the TypeScript, you read, approve, and monitor it in the dashboard. But you need to understand this connection to trust the result and know where to look when something goes wrong.
📊 Before moving on, this should be clear
- Local: depends on your computer being on—good for testing, bad for relying on.
- Cloud: a remote server that never shuts down on your behalf — it runs on its own.
- Pipeline: code → repository (git) → execution platform → logs dashboard.
- You: asks, reads, approves, and monitors — you don’t need to write or read TypeScript line by line.
🎯 Main Concept
- •Real automation is measured by your absence—if it needs you to be there, it’s still a manual task in disguise.
- •Going beyond local isn’t “too advanced” — it’s a series of small steps, each covered in a module in this track.
Quick check (optional): what really separates “running locally” from “real automation”?