The path of track 6: the code goes up to the cloud (GitHub + Trigger.dev), gets secured (secrets and RLS), and gains robustness and monetization — the final leap from prototype to product.
Learning path map
Detailed content
🚀 GitHub & Trigger.dev
The two pillars of hosted automation: GitHub as cloud code storage (commit, push, history) and Trigger.dev as the execution engine (no timeout, retries, traces, alerts). Initialize the project, schedule it with cron, and read the dashboard.
Cloud code storage: deploy pulls from there (not from your machine), you can access it from anywhere, and you have history to revert to.
It’s a prerequisite for hosting: deploy platforms integrate directly with the repo.
Repo = project folder; commit = snapshot; push = send to the cloud.
GitHub's command-line tool (gh) authenticates and connects the project; .gitignore lists what must never be pushed—the golden rule is .env.
A leaked .env is a leaked secret; .gitignore is the first line of defense.
gh auth login; .gitignore; secret kept outside the repo.
The cloud execution engine: runs tasks without timeouts, with automatic retries, a trace of every step, and failure alerts. Like a reliable assistant, not a sticky note.
It’s what closes the “agentic gap”—it provides visibility when AI is no longer being supervised.
Runs TypeScript (the AI writes it); official MCP; dev vs. prod.
Install the official MCP, copy the Project ID, and run init — which creates trigger.config.ts and the tasks folder; dev starts the local worker.
With the MCP, you manage the project by chatting; without it, you end up in the terminal.
interactive init; restart after installing MCP; Project ID.
A 5-field pattern (minute, hour, day of month, month, day of week) that defines when the task runs. 0 7 * * * = every day at 7 a.m.
It’s what makes automation run without you being there—it scales beyond “show up and trigger it.”
5 fields; * = any; */5 = every 5.
The production window: a list of runs, traces (each row = one step), payload/output, a schedules section, queues and alerts, and two environments (dev and prod).
Now that the AI is no longer monitoring things, the dashboard is where you see what happened.
Run = execution; trace = step-by-step; test in dev, release in prod.
The discipline of building with deployment in mind from the start: the “one initial prompt to rule them all” asks for fixed inputs, structured output, error handling, and logging from the beginning.
In production, AI won’t fix things on its own; anything you didn’t ask for in the prompt doesn’t come for free.
Deploy from the 1st prompt; commit → push → deploy loop; check the run.
🔐 Secrets & Security
How to keep keys and data safe: environment variables (local vs. cloud), .env.example and reading via process.env, OAuth & refresh tokens, the golden rules for secrets, Row-Level Security to isolate data, security auditing, and why an open app is a financial risk.
The secret is stored outside the code and injected only at runtime—so the code never contains the key.
It’s the mechanism that separates “what’s public” (code) from “what’s secret” (keys).
External secret; injected at runtime; code with no embedded key.
Locally, secrets live in .env; in the cloud, they live in the Environment Variables dashboard (Trigger.dev/Vercel), which injects them at runtime. Trigger.dev doesn't read the local .env.
Forgetting to add the key in production is the failure that "only shows up in prod".
Two environments (dev and prod); check both; the cloud can’t read the local .env.
A .env.example lists keys WITHOUT values (safe to commit); the code reads values via process.env and never writes them directly.
Document which secrets the project needs without exposing any of them.
.env.example = names only; process.env = reading; nothing hard-coded.
OAuth delegates access to a service (e.g., Google) without exposing your password; the refresh token renews access automatically. When the standard flow fails, a terminal script generates the token.
It's how hosted agents access Sheets, Drive, and Gmail without you logging in every time.
Client ID/secret; refresh token; terminal fallback.
The three non-negotiable rules: never paste keys into the AI chat, never commit .env, and rotate/regenerate keys (ideally, use different keys for local and production).
An API key is like access to a credit card: if it leaks, someone can spend on your behalf.
Key = card; .gitignore; rotate and separate dev/prod.
Row-Level Security: rules that live in the database itself (Supabase) and prevent one user from seeing another user’s data—even if there’s a bug in the frontend.
It’s an extra layer: the database protects the data independently of the app.
Database rule; isolation by user; defense in depth.
Ask the AI to act as a security specialist and check: protected routes, no keys exposed in the frontend, secrets only in env vars, and RLS enabled.
Before putting the app into production, an explicit audit catches what slipped through.
Checklist of 4 points; clean context; fix whatever fails.
An app without authentication on the internet can be triggered by anyone with the URL — and each trigger uses your AI key. You pay for other people's usage.
Justifies adding login (Supabase) and usage limits before sharing it.
Public URL = open door; authentication; usage limits.
🛡️ Reliability & Monetization
What separates “works once” from “reliable and profitable”: the agentic gap revisited, meaningful logging, try/catch in external calls, retries with backoff (vs. logic bugs), failure alerts, the human debugging loop, and monetization with Stripe (product, webhook, subscriptions, freemium).
Once it’s live on a schedule or event, the AI is no longer reading errors and fixing them: the task runs, but doesn’t adapt on its own. That’s the agentic gap.
It's why you build in error handling and logging from the 1st prompt — you can't count on self-healing.
It runs but doesn’t adapt; visibility through the platform; human feedback loop.
Specific logs at every relevant step: "the search returned 429 from source 3," not "the task failed." The message needs to be actionable.
A vague log is useless; a log with context is what makes the error diagnosable.
Specific > generic; context (status, source); each step.
Wrap every external API call in try/catch: log the error with context, continue where possible, and only "throw" on critical failures.
It’s what makes the task write a partial line instead of freezing when an API fails.
try/catch per call; continue; throw only for critical errors.
Configure the task to retry (e.g., up to 3 times, with exponential backoff starting at 30s). Retries solve transient API problems—not code bugs.
Knowing the difference helps you avoid endlessly repeating a mistake that will never work.
Exponential backoff; transient vs. logical; retry limit.
Set up failure alerts in the dashboard by email, Slack, or webhook—choosing the environment and type of failure. It takes less than two minutes.
You want to know about the outage before the end user notices.
Alert channel; per environment; every task must have an alert.
AI still debugs, just not automatically: you open the red trace, copy the error, paste it into the AI ("here's the trace that failed; what's wrong?"), apply the fix, and redeploy.
It’s a substitute for self-healing—quick diagnosis, but with a human passing along the error.
Red trace; copy and paste; redeploy and test.
Add payments with Stripe and turn it into a freemium SaaS: a free tier (e.g., 2 uses/day) and a paid tier (e.g., $29/month unlimited) via Stripe Checkout, with a webhook listening for subscription events.
Complete the transition from “just a workflow” to a product that generates revenue and limits your costs.
4 keys (publishable, secret, price ID, webhook secret); freemium; subscription table.