🟣 Hosting & Deploy

Scripts that run on the internet on their own, on a schedule (cron), or triggered by an event (webhook), without a human present to start or monitor them.

Human-triggered automation only scales as fast as someone shows up to click; hosting is the leap to autonomy.

Local → hosted; cron vs. webhook; Trigger.dev as the engine; GitHub as storage.

The gap that appears when a task runs on its own: AI is no longer there to read the error and self-heal, so the system executes but does not adapt.

In production, a failure can go unnoticed; you need to close the gap with platform features and better prompts.

End of the self-healing loop; fixed inputs, structured outputs; errors and logging built in from the start.

A 5-field timing pattern (minute, hour, day of month, month, day of week). Example: 0 7 * * * = 7 a.m. every day.

It's the universal scheduling language; knowing how to read it keeps you in control of when the automation runs.

Five fields; * = anything; recurring schedule; the keyword "runs on its own".

GitHub is cloud code storage: deploy pulls from there (not from a local machine), with version history for rollback and troubleshooting.

It's the single source of truth for the code that goes to production, accessible from any computer.

Repository = project folder; commit (snapshot) and push (send); private repo + README.

The command-line tool (gh) authenticates and connects the local project to the repository; .gitignore lists what should never be pushed.

The golden rule: the file .env with the keys NEVER goes to GitHub.

gh auth login; automatic .gitignore; secrets kept out of version control.

The cloud execution engine: no timeouts, automatic retries, complete traces of every step, support for schedules and webhooks, and failure alerts.

It's what makes automation reliable — like a dependable assistant, not a note stuck to the fridge.

TypeScript (the AI writes it); official MCP; dashboard as a window into production.

Install the Trigger.dev MCP, run the init (creates trigger.config.ts and the tasks folder), start the dev worker, and learn the anatomy of the dashboard.

Without the project initialized and the worker running, tasks won’t register or execute.

Project ID; interactive init; dev vs. production; runs, traces, payload, and output.

Environment variables stored in the Trigger.dev dashboard and injected at runtime, with a .env.example safe to version-control.

Trigger.dev doesn’t read the local .env; without secrets in the cloud, the task breaks in production.

Runtime injection; never paste the key into chat; check dev e prod separately.

A scheduled task that runs every morning: cron triggers, Firecrawl researches a fixed topic, AI synthesizes, and a row is written to Google Sheets.

It's the complete scheduled build, from prompt to deploy, running with no one watching.

Unsupervised task; hard-coded topic; single file; test trigger in the dashboard.

The one-time setup for Google's refresh token (OAuth); when the Playground fails ("access blocked"), the fallback is a terminal script that prints the URL and returns the token.

Without the refresh token, the task can’t write to Sheets autonomously.

Client ID + secret; refresh token; OAuth (not a service account); .env + cloud environment variables.

A real failure: the API returns an unexpected format (results in web, not in data); copy the trace so the AI can diagnose and fix the parsing.

Some errors only show up with real data in production — knowing how to read them and feed them back to the AI is the core skill.

Different response shape; red trace; redeploy + retrigger; error as input.

A task triggered by a webhook: a JSON payload with fields (company, industry, goal, challenge) generates a report .docx saved in Google Drive.

It's the event-driven build — the complement to the scheduled one, triggered by incoming data.

Normalize form fields; folder ID optional; test locally before the form.

A webhook is a URL that listens for incoming data and wakes up the task, passing the payload along — a "digital doorbell."

Without authentication, anyone can call your task; the header Authorization: Bearer protects the endpoint.

URL with the task ID; JSON body; Bearer + API key; shareable URL.

Iterating in the editor pushes the code to GitHub, which automatically deploys it to Trigger.dev—the latest files are always live.

Close the iteration loop: you make a change, push it, and production updates automatically.

Repository Secret (TRIGGER_ACCESS_TOKEN); GitHub Actions; commit → push → deploy.

A layered approach: meaningful logs at every step, try/catch around each external call, retries with backoff, and email/Slack alerts.

Without production self-healing, error handling is what closes the agentic gap.

Specific logs (not "task failed"); retries for transient failures, not bugs; alerts configured.

The production cycle: open the red trace in the dashboard, copy the error, paste it into the AI, and let it diagnose, fix, and redeploy.

The AI still debugs, but no longer on its own—a human needs to bring the error to it.

Trace + AI = fast diagnosis; human as the bridge; iterate until it passes.