Until now, the automation ran on your machine when you told it to. To run on its own over the internet, three pieces come together: the code lives in GitHub, o Trigger.dev runs, and the trigger is an schedule (cron) or a event (webhook). The diagram shows how they connect.
Illustrative diagram — conceptual recreation of the deployment infrastructure, not a real screenshot.
☁️ Hosted automations
What it is
A hosted automation is a script that runs on the internet on its own—without you opening anything or clicking "run." Instead of the automation living on your machine and depending on you being there, it lives in the cloud and starts on its own: for schedule (cron) or via event (webhook). This is the shift from "run when I tell it to" to "run on its own."
Why learn
The main limitation of human-triggered automation is simple: it only scales as fast as a person can show up and click. If a task needs to run every morning at 7 a.m., or the moment a form is submitted, relying on you becomes a bottleneck. Hosting removes that bottleneck.
- •Runs without supervision: the task happens even while you’re asleep or on vacation.
- •Scale of truth: the frequency no longer depends on your availability.
- •Reliability: with retries and logs, failures are handled and visible.
Key concepts
✓ What changes when you host it
- ✓The code leaves the machine and goes to the cloud.
- ✓The trigger becomes a schedule or event, not a click.
- ✓An engine (Trigger.dev) handles execution, retries, and logs.
✗ What Hosting Is NOT
- ✗Leave the computer on with the editor open all night.
- ✗Run the task manually “when I remember.”
- ✗Depend on you to click before anything happens.
🎯 Practical tip
Two builds anchor this track: one scheduled research agent (cron, every morning) and a webhook report generator (event-triggered). Keeping them in mind helps you understand why each piece of infrastructure exists.
🕳️ The "agentic gap"
What it is
In an interactive session, the AI observes each error, diagnoses it, and fixes it—the famous self-healing loop. When the task starts running on its own in the cloud, this loop disappears: the AI is no longer there watching. The agentic gap is this gap—the system runs but doesn't adapt on its own, and a failure can go unnoticed by both the AI and you.
Why learn
✓ How to close the gap
- ✓Automatic retries with configurable terms.
- ✓Complete traces of every execution step.
- ✓Failure alerts (email/Slack) and no timeout.
✗ What Goes Away
- ✗The AI reading the error and fixing it on the spot.
- ✗Spontaneous adaptation to a new scenario.
- ✗Guarantees someone will notice the breakage.
Key concepts
Since AI won't self-heal in production, unsupervised builds need four things from the first prompt: fixed inputs, structured and predictable outputs, built-in error handling, and logging at every step. The keywords "runs on its own" and "every morning" signal to the AI to design for a schedule, without a human in the loop.
No questions along the way.
Predictable format.
Handle errors from the start.
Full visibility.
⏰ Cron
What it is
O cron is a five-field timing pattern that says when a task should run. The fields, in order, are: minute, hour, day of the month, month, and day of the week. An asterisk (*) means "any value." The classic 0 7 * * * reads as "at minute 0 of hour 7, every day, every month, every day of the week"—in other words, 7 a.m., every day.
# ┌───────── 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
Why learn
Cron is the universal scheduling language—it appears in Trigger.dev and practically every automation platform. Knowing how to read and write these five fields puts you in control of when the task runs, without relying on guesswork or a limited graphical interface.
🎯 Practical tip
You don’t need to memorize the syntax: describe the schedule in natural language (“every morning at 7 a.m.”) and let the AI generate the cron expression. But recognizing the five fields helps you check whether what it generated matches what you wanted.
Minute, hour, day, month, day of week.
Wildcard in each position.
Triggers in a loop.
7 a.m. every day.
🗄️ GitHub as code storage
What it is
O GitHub is cloud code storage. Instead of the code living only on your machine, it lives in a repository (the project folder in GitHub) — accessible from any computer, with a complete version history for rollback and troubleshooting. Deploy platforms like Trigger.dev pull the code directly from there.
Why learn
For an automation to run in the cloud, the code needs to be somewhere the cloud can access. GitHub is that place—the single source of truth for what goes to production. As a bonus, the commit history lets you revert to a working version when something goes wrong.
- •Access from anywhere: the code isn’t tied to a device.
- •History + rollback: each commit is a restore point.
- •Deploy integration: Trigger.dev pulls directly from the repository.
Key concepts
Git vocabulary
Repository (repo)
The project folder in GitHub, which stores all commits. Make it private and initialize it with a README.
Commit
A saved snapshot of the code, with a description of the changes. It’s your restore point in the history.
Push
The act of sending commits from your machine to GitHub. The assistant connects the local folder to the repo and makes the first commit for you.
🎯 Practical tip
Choose a clean local path (e.g., Documents) and avoid putting the project in a cloud-synced folder. You’ll see several permission requests for bash commands — approving them is normal, not an error.
🔒 gh CLI & .gitignore
What it is
O gh (GitHub CLI) is the command-line tool that authenticates and connects the local project to GitHub. The .gitignore is a file that lists what never should be pushed to the repository. Together, they let you push code safely—and keep secrets out of the public cloud.
Why learn
⚠️ The golden rule: .env never gets pushed
The file .env stores API keys. If it ends up in a repository (even a private one), your keys are exposed. The assistant adds the .env when .gitignore automatically — but check.
- ✗Never commit the
.env— the starting point helps, but trust the.gitignore. - ✗Never paste API keys into the chat.
- ✗Don’t assume a “private repo” is safe for secrets.
Key concepts
Installing and authenticating gh
Package manager prerequisite
On macOS, install Homebrew first; on Windows, WinGet. Then, brew install gh (or the equivalent).
Authenticate with gh auth login
Choose GitHub.com, HTTPS, browser authentication; paste the one-time code and authorize.
Connect and verify
The assistant connects the local folder to the repo, pulls the README, writes the .gitignore and confirms the sync.
🎯 Practical tip
Choose a professional public username — it appears on your profile. And remember: repeated permission requests for bash commands during the connection are expected; read along to understand each step.
🚀 Trigger.dev
What it is
O Trigger.dev is the cloud execution engine—like a dependable assistant you can count on, not a reminder stuck to the fridge. It runs tasks no timeouts (as long as needed), with automatic retries, complete traces for each step, support for schedules and webhooks, and failure alerts. It runs on TypeScript—but the AI writes the TypeScript, so the vibe coding approach doesn’t change.
Why learn
✓ What Trigger.dev delivers
- ✓No timeout: long-running tasks keep running until they finish.
- ✓Automatic retries for transient failures.
- ✓Traces + alerts + official MCP for the AI to manage.
📊 Why TypeScript Is Not a Problem
- •The AI generates all the TypeScript code from the conversation.
- •You keep describing the result instead of writing code.
- •The prompting flow is exactly the same as in the previous phases.
Key concepts
The division of responsibility is clear: the GitHub stores the code; the Trigger.dev runs — scheduling, webhooks, retries, logging, and alerts. The Trigger.dev dashboard is your window into what's happening in production, which helps close the agentic gap precisely because the AI is no longer watching for errors.
Runs as long as needed.
Try again on your own.
Every step recorded.
Production window.
🧰 Initialize Project + Trigger.dev MCP
What it is
Initializing the project means installing the Official Trigger.dev MCP (which lets AI manage the project through conversation), run the init (creates the trigger.config.ts and the tasks folder) and push the dev worker so tasks can be registered and run. You create the Trigger.dev account with GitHub, and the project gets the same name as the repository.
Why learn
The startup sequence
Install the MCP and restart
Ask the AI to install the Trigger.dev MCP; approve the commands. Restart the assistant afterward — otherwise, the server may not appear (a common cause of errors).
Copy the Project ID and run init
Get the Project ID in Project Settings > General. The init is interactive and may need to run in the terminal; choose the "hello world" example.
Start the dev worker and confirm
Run the dev worker to register the task; confirm that “hello world” appears in the dashboard. Ask the AI to trigger it and inspect the run, traces, payload, and output.
Key concepts
✓ Dashboard anatomy
- ✓Task view, Runs list, and traces for each execution.
- ✓Timeline, payload and output panels.
- ✓Sections on Schedules, Queues, and Alerts.
✗ Common Pitfalls
- ✗Forget to restart after installing the MCP.
- ✗Wait for the non-interactive init (sometimes it needs the terminal).
- ✗Confuse the development environment with production while testing.
🎯 Practical tip
Always open the project folder in the editor so the AI can manage it through conversation instead of dropping into the terminal. Build and test in dev; only promote it to production when you’re ready to go live.
🗝️ Secrets management
What it is
Keys and secrets must never live in public code — and Trigger.dev can't read the .env local. The solution is to store the secrets in the Environment Variables from Trigger.dev: they stay out of the code and are injected at runtime, only when the task runs. Locally, you keep a .env (git-ignored) for development.
Why learn
Without the secrets in the cloud, the task works locally but breaks in production—because there it doesn’t have access to your .env. The assistant creates the .env, makes sure it's in the .gitignore, generates a .env.example safe to version-control and updates the code to read from process.env.
- •Local:
.envon the machine, for development. - •Cloud: Trigger.dev Environment Variables, injected at runtime.
- •Versionable: only the
.env.example(without real values) is pushed to the repo.
Key concepts
⚠️ The three golden rules
- ✗Never paste API keys into the assistant's chat.
- ✗Never commit the
.envon GitHub. - ✗Don’t forget to add the variable to the production, not just in the dev one.
🎯 Practical tip
As you add each key (e.g., Anthropic, Firecrawl, Google Sheets via OAuth), mark dev AND prod — forgetting the production environment is one of the most common reasons a task works in testing but fails when it goes live. Consider rotating keys and using separate keys for local and production environments.
Self-healing (optional): the task works in the local test, but fails in production saying an API key is missing. Where is the problem most likely?
📌 Module Summary
0 7 * * * = 7 a.m. every day.Next Module:
3.2 — Agents in Production: Scheduled Jobs & Webhooks