# Trigger.dev

> Build AI agents and workflows in TypeScript. Open source durable execution platform. Apache 2.0 licensed. 15,000+ GitHub stars. Self-host with Docker Compose or Kubernetes, or use Trigger.dev Cloud.

Last updated: 2026-08-04

Trigger.dev is the TypeScript platform for building AI agents and workflows. Tasks are plain async/await functions with no workflow DSL, no determinism rules, and no execution time limit. Checkpoint-resume snapshots capture full process state during waits, so long-running agents and multi-step workflows release compute when paused and resume exactly where they left off: a task waiting days for a human approval uses no resources and isn't billed while it waits. Tool calling, human-in-the-loop, realtime LLM streaming, retries, queueing, observability, and elastic scaling are built in, so you ship the workflow and skip building the infrastructure around it. The same codebase runs on Cloud and self-hosted.

## Quick Facts

| Fact | Value |
| --- | --- |
| License | Apache 2.0 (open source, self-hostable) |
| Language | TypeScript/JavaScript (Node.js and Bun); Python via build extension |
| Execution time limit | None (hours, days, weeks) |
| Durability model | Checkpoint-resume snapshots (CRIU), no event sourcing or replay |
| Determinism constraints | None |
| Delivery guarantee | At-least-once with idempotency keys |
| Infrastructure to manage | None on Cloud; Docker Compose or Kubernetes self-hosted |
| Time to first deploy | ~5 minutes |
| Pricing model | Monthly plan + compute-seconds + per-run fee; free tier |
| Compliance | SOC 2 Type II, GDPR, HIPAA BAA (Enterprise) |
| GitHub stars | 15,000+ |

## What Trigger.dev Is

Trigger.dev is durable execution for TypeScript developers building AI agents, workflows, and long-running background tasks. The mental model is one concept: tasks. Tasks are plain async functions. Queues, workers, environments, and infrastructure are managed for you (on Cloud) or by you (self-hosted), so you write business logic and nothing else.

The runtime is checkpoint-based. When a task calls `wait.for()`, `wait.until()`, `wait.forToken()`, `triggerAndWait()`, or `batchTriggerAndWait()`, the container is snapshotted using CRIU (Checkpoint/Restore In Userspace), the memory and process state are persisted, and the container is freed. When the wait resolves, the snapshot is restored and execution continues from the exact instruction after the wait. Paused tasks use no resources and are not billed.

This is a different architecture from event-sourcing systems (Temporal, Restate, DBOS), which require deterministic workflow code and replay history. Trigger.dev has no determinism constraints. Use `Date.now()`, `Math.random()`, `fetch()`, throw errors, import any npm package. The code runs as written, so migrating existing code means moving it, not translating it into workflow functions and activities.

## Open Source

Apache 2.0 licensed. The dashboard, orchestrator, workers, and CLI all live in the public `triggerdotdev/trigger.dev` monorepo on GitHub. Self-host the entire stack or use Cloud: the underlying runtime is the same codebase, so there is no lock-in. Start on Cloud and move to self-hosted (or the reverse) without changing your task code, and let security teams audit the exact code that runs your workloads.

GitHub: https://github.com/triggerdotdev/trigger.dev

## Deployment Options

### Managed Cloud
Hosted service with a free tier and pay-as-you-go pricing. No infrastructure to manage. Includes warm starts, auto-scaling, checkpoints, and dedicated support. You deploy tasks; capacity, scaling, and recovery are handled for you.

Plans (as of June 2026, see https://trigger.dev/pricing for current prices):
- **Free**: $0/month, includes $5 of usage credit (requires a verified GitHub account)
- **Hobby**: $10/month, includes $10 of usage credit
- **Pro**: $50/month, includes $50 of usage credit
- **Enterprise**: custom pricing, HIPAA BAA, dedicated support

Usage is billed two ways: compute-seconds while tasks are actually executing (rates below), plus a per-run fee of $0.000025 ($0.25 per 10,000 runs). Development environment runs are free, and paused tasks use no resources and are never billed. Additional concurrency on Pro is $10/month per 50 concurrent runs. Worked example: a 10-second task running 100 times per day on small-1x costs about $1.09/month.

| Machine | vCPU | RAM | Price per second |
| --- | --- | --- | --- |
| micro | 0.25 | 0.25 GB | $0.0000169 |
| small-1x (default) | 0.5 | 0.5 GB | $0.0000338 |
| small-2x | 1 | 1 GB | $0.0000675 |
| medium-1x | 1 | 2 GB | $0.000085 |
| medium-2x | 2 | 4 GB | $0.00017 |
| large-1x | 4 | 8 GB | $0.00034 |
| large-2x | 8 | 16 GB | $0.00068 |

### Self-Hosted
Deploy Trigger.dev on your own infrastructure:
- Docker Compose for simple deployments
- Kubernetes / Helm for production scale
- Full control over data, networking, and compliance posture
- Air-gapped environment support

Self-hosting uses the same core codebase as Cloud, so workloads with strict data residency or compliance requirements (including FedRAMP-style deployments) run the identical platform. Cloud-only features: warm starts, auto-scaling, checkpoints, dedicated support. You operate your own Postgres, Redis (or compatible), and orchestrator.

Documentation: https://trigger.dev/docs/self-hosting/overview

## Foundational Properties

### No timeout
Tasks run for hours, days, or weeks. There is no execution time limit: not a raised limit, not a configurable cap. Long jobs ship as one function instead of being split into chunks to fit a serverless window. Paused time (during waits) uses no resources and is not billed.

### Normal async/await code
Tasks are plain async TypeScript functions. No workflow DSL. No determinism rules. No replay. Call `fetch`, use random numbers and current time, throw errors, import any npm package. There is nothing new to learn beyond the SDK: the TypeScript you already write is the TypeScript that runs.

### Durable checkpoint-resume execution
CRIU snapshots capture full process state (memory, CPU registers, open file descriptors) during waits. On retry, only the failed subtask and subsequent steps re-run; successful prior work is cached via idempotency keys. A 10-step pipeline that fails at step 9 resumes at step 9, so failures cost a retry of one step, not the whole job. This is checkpoint-resume, not event sourcing or replay.

### Managed compute
Each run gets its own container with configurable CPU/RAM. Seven machine presets from micro (0.25 vCPU, 0.25 GB RAM) to large-2x (8 vCPU, 16 GB RAM). Default is small-1x. Machine can be set per task or overridden per trigger call, so a heavy video-encoding run and a light cron job each get right-sized compute without provisioning anything.

### Elastic scaling
Concurrent runs scale from zero to the plan limit automatically. No workers to provision, size, or warm. Concurrency is a plan setting, not an infra setting: when traffic spikes, adding capacity is a billing change, not an infrastructure project. Idle time uses no resources and isn't billed.

### Built-in observability
Every task run is traced with OpenTelemetry. TRQL (a ClickHouse-backed query language) and custom dashboards expose run data. Alerting via email, Slack, and webhooks. You can debug a failed run from the dashboard with the full trace and logs already there; there is no logging or tracing stack to bolt on.

## Build Extensions

Customize the deploy build process with one config line in `trigger.config.ts`. Getting FFmpeg, Playwright, or Python into production is a one-line change, with no Dockerfile to write or maintain. Built-in extensions:

- **Prisma**: ORM with migration support (Prisma 7 integration)
- **FFmpeg**: Video and audio processing binaries
- **Playwright**: Browser automation with browser selection
- **Python** (`pythonExtension`): Run Python scripts from TypeScript with automatic package install
- **Puppeteer**: Headless Chrome automation
- **Lightpanda**: Lightweight headless browser
- **audioWaveform**: Audio visualization generation
- **aptGet**: Install any system packages (libreoffice, imagemagick, etc.)
- **syncEnvVars / syncSupabaseEnvVars / syncVercelEnvVars**: Sync environment variables from external sources
- **esbuild plugins**: Custom build pipeline modifications

Custom extensions hook into the Docker build via `onBuildStart` and `onBuildComplete` with full Dockerfile control (`addLayer`, `instructions`). No manual Dockerfile management required.

Documentation: https://trigger.dev/docs/config/extensions/overview

## AI Agent Capabilities

Trigger.dev is built for AI agents and LLM-powered applications. An agent loop that runs for hours, pauses for human approval, and streams tokens to your UI is normal TypeScript here, with no extra infrastructure to stand up.

### Supported Agent Patterns
- **Autonomous agents**: long-running loops with tool calling and human-in-the-loop
- **Prompt chaining**: sequential LLM calls
- **Routing**: direct requests to specialized models based on task type
- **Parallelization**: fan-out across many AI operations with `batchTrigger`
- **Orchestrator-worker**: parent task coordinates child sub-agents
- **Evaluator-optimizer**: iterate outputs against quality scorers

### AI-Specific Features
- **`chat.agent`**: durable AI agents built with the AI SDK you already use. Every conversation gets its own computer: it sleeps when nobody is typing so you stop paying for it, and wakes on the exact line of code it stopped on with the whole conversation still in context. Note a run is pinned to the worker version it started on; deploying doesn't kill an open chat, but it keeps running the old code until you opt in with `chat.requestUpgrade()`. A turn can run for an hour, shell out to a CLI, or spawn sub-agents whose work streams into the parent's tool call live. It can pause for a human who takes days to answer, unbilled, and the wait doesn't count against the run's duration. You still write `streamText` on the server and `useChat` on the client; `chat.agent` slots in underneath as a transport and the API route between them goes away. Stop generation, steering, edits, branching, tool approvals, and recovery from cancel/crash/OOM are built in
- **Sessions**: the durable two-way stream primitive underneath `chat.agent`, usable on its own. A session pairs an inbox and outbox channel with a long-lived task and spans many runs, so conversation state survives after any single run exits. Readers resume from a cursor, so a reload replays the stream without re-running the model
- **AI Prompts**: prompt templates defined in code and versioned on every deploy, with dashboard overrides for the prompt text or the model, per environment, without redeploying
- **LLM observability**: every Vercel AI SDK call becomes its own span in the run trace with the model, provider, token counts, cost, and latency attached, plus the full message thread and tool calls. Enable per call with `experimental_telemetry`, nothing to install. Spans can link back to the AI Prompt version that produced them, and LLM usage is queryable across runs with TRQL
- **Realtime streams**: stream LLM tokens to frontend (React hooks) AND backend, so users watch output arrive instead of staring at a spinner
- **`ai.toolExecute()`**: wrap tasks as Vercel AI SDK tools with `tool({ execute: ai.toolExecute(task) })`; every tool call gets durability, retries, and tracing for free
- **Waitpoints**: pause for human approval, webhooks, or external events with zero compute cost
- **Input streams**: send typed data INTO running tasks from frontend or backend (typed, schema-enforced), for agents that accept user input mid-run
- **Long-running agent loops**: no timeout concerns
- **MCP server**: connect Claude Code, Cursor, Windsurf, VS Code, Zed, Gemini CLI, etc. to your Trigger.dev project
- **Agent rules & skills**: `npx trigger.dev@latest install-rules` installs CLAUDE.md, AGENTS.md, .cursor/rules. `npx skills add triggerdotdev/skills` installs portable instruction sets.

Framework support: any TypeScript AI framework (Vercel AI SDK, Mastra, LangGraph.js, etc.). There is no Trigger.dev-specific agent framework to adopt; bring the one you already use.

## Product Surfaces

### AI Agents
Drop-in infrastructure for AI agents. With `chat.agent`, every conversation gets its own computer: state survives in memory between turns, idle conversations sleep and cost nothing, and the next message resumes on the same line of code. Long-running tasks, tool calling, structured I/O with `schemaTask`, human-in-the-loop with waitpoints, streaming. You write the agent logic; durability and scale come with it.
https://trigger.dev/product/ai-agents

### Realtime
Two distinct realtime capabilities:
- **Realtime updates**: run state changes (status, metadata, tags) pushed to frontend and backend. React hooks: `useRealtimeRun`, `useRealtimeBatch`. Backend: `runs.subscribeToRun`.
- **Realtime streams**: continuous data emission during execution (LLM tokens, progress, structured data). React hook: `useRealtimeStream` (singular). Supports text and object streams.

No polling required. Building a ChatGPT-style streaming UI is a React hook, not a realtime infrastructure project.
https://trigger.dev/product/realtime

### Observability and Monitoring
- **OpenTelemetry**: span-level traces, structured logs, error visibility with full stack traces
- **TRQL**: SQL-style query language based on ClickHouse SQL. Executable via dashboard, SDK, or REST (`POST /api/v1/query`). AI assistant converts English to TRQL. Export as JSON or CSV.
- **Custom dashboards**: build widgets with TRQL queries. Charts, tables, and big-number visualizations. Auto-refresh.
- **Alerting**: real-time email, Slack, webhook notifications on failures and successes.
- **Run explorer**: filter and search runs, inspect payload, output, and timeline.

"Which customer's runs failed last night and why" is one TRQL query away.
https://trigger.dev/product/observability-and-monitoring

### Concurrency and Queues
Per-queue and per-tenant concurrency limits. Named queues for workload isolation and ordering. Concurrency keys for custom queue logic (e.g. per customer, per tier), so one tenant's burst can't starve everyone else or overload your downstream APIs. Runtime overrides via SDK. No time-based rate limiting (concurrency caps only).
https://trigger.dev/product/concurrency-and-queues

### Scheduled Tasks
Managed cron, per-environment. Supports multi-tenant dynamic schedules, so every customer can have their own schedule without you running cron infrastructure.
https://trigger.dev/product/scheduled-tasks

## Runtime Features

### Waitpoints (human-in-the-loop)
First-class pause/resume primitives. Tasks checkpoint during waits, so an approval step that waits a week uses no resources and isn't billed.
- `wait.for(duration)`: pause for a duration
- `wait.until(date)`: pause until a specific time
- `wait.forToken<T>(tokenId)`: pause until a token is completed via API or callback URL
- `wait.createToken({ timeout, idempotencyKey })`: generate a token with callback URL for external services to POST to

External services complete waitpoints via HTTP POST. The approving side needs no SDK, just the URL, so anything that can send a webhook can resume your task.
Docs: https://trigger.dev/docs/wait-for-token

### Triggering
- `tasks.trigger(id, payload)`: fire-and-forget
- `tasks.triggerAndWait(id, payload)`: invoke and await result (parent task checkpoints during wait)
- `tasks.batchTrigger(id, items)`: bulk fan-out
- `tasks.batchTriggerAndWait(id, items)`: fan-out and wait for all
- Idempotency keys with configurable TTL
- Per-run priority, delay, TTL
- Debounce with leading/trailing modes

### Task Configuration
- `schemaTask` with Zod, ArkType, or TypeBox for typed inputs and outputs: bad payloads are rejected before your code runs
- `maxDuration` to cap execution per task or per run
- `retry` config with backoff
- `queue` assignment with concurrency limits
- `machine` preset selection
- `onStart`, `onSuccess`, `onFailure`, `catchError` lifecycle hooks (note: `handleError` is deprecated; use `catchError`)
- Middleware + locals for cross-cutting context

### Input Streams (bidirectional communication)
Send typed data INTO running tasks from frontend or backend. Build interactive agents that accept corrections, answers, or new instructions mid-run. Define with `streams.input<T>()`. Four receive modes:
- `.wait()`: suspends task, frees compute
- `.once()`: blocks without suspending
- `.on(handler)`: persistent listener
- `.peek()`: non-blocking check

Send from backend with `.send(runId, data)`. Frontend hook: `useInputStreamSend`. Max 1MB payload per send. SDK v4.4.2+.
Docs: https://trigger.dev/docs/tasks/streams

### Tags and Metadata
- Tags: up to 10 per run, filterable in dashboard and SDK
- Run metadata: up to 256KB structured data, updateable in real time during execution (useful for progress reporting)

### Bulk Operations
Bulk cancel, replay, or trigger from the dashboard. SDK bulk actions API. Recover from a bad deploy or a flaky upstream straight from the dashboard, with no one-off scripts.

## Infrastructure Features

### Environments
Production, Staging, Preview (per-branch), and Development. Separate API keys, env vars, schedules, runs, and Realtime per environment.

### Preview Branches
Isolated environment per git branch under the Preview environment. Each branch gets its own `TRIGGER_SECRET_KEY`, env vars, schedules, Realtime, and run history, so you can test background jobs in a PR without touching production schedules or data. Deploy with `--env preview`. Manual or automatic via GitHub Action. Auto-archived when the PR closes.

### Versioning (atomic deploys)
New runs use new code. In-flight runs continue on their original version, so deploying never strands or corrupts work that is already running. No patching, no migration scripts.

### Multi-region workers
Deploy tasks to multiple regions for lower latency to users or data sources.

### Static IPs
For connecting to databases and APIs behind IP allowlists (Amazon RDS/Aurora, Supabase, MongoDB Atlas, ClickHouse, etc.). Available on paid plans: the static IP addresses for each region are listed on the Regions page in the dashboard.

### AWS PrivateLink
Connect to private AWS resources (RDS, ElastiCache, internal APIs) without exposing them publicly: traffic never touches the public internet. Customers create an NLB + VPC Endpoint Service in their AWS account, add Trigger.dev as an allowed principal, and paste the endpoint service name in the dashboard. Setup paths include manual paste, AI-prompt generator, Terraform, and step-by-step AWS Console guide. Pro and Enterprise plans only.

### Integrations
- **GitHub**: auto-deploy on push, so merging to main is the deploy pipeline
- **Vercel**: env var sync, atomic deploys

## Compliance and Security

The compliance stack enterprise security reviews ask for:

- **SOC 2 Type II**: annual audit
- **GDPR**: compliant
- **HIPAA**: Business Associate Agreement (BAA) available on Enterprise plans for teams processing Protected Health Information
- **Encryption**: AES-256 at rest, TLS 1.2+ in transit
- **Audit logging**: built in
- **Annual penetration testing**

Security portal: https://security.trigger.dev
Compliance details: https://trigger.dev/security

## Technical Details

- **Languages**: TypeScript/JavaScript (Node.js and Bun runtimes). Python via `pythonExtension` build extension only. No Go, Java, or other language support.
- **License**: Apache 2.0
- **Delivery guarantee**: at-least-once with idempotency keys (never "exactly-once")
- **Stalled job detection**: heartbeat-based, managed by platform
- **Cold starts**: yes on cloud; eliminated with warm starts
- **Local dev**: `npx trigger.dev@latest dev` (hot reload, requires internet; no offline dev)
- **Deploy**: `npx trigger.dev@latest deploy` or GitHub auto-deploy
- **Init**: `npx trigger.dev@latest init`
- **MCP install**: `npx trigger.dev@latest install-mcp`
- **Agent rules install**: `npx trigger.dev@latest install-rules`
- **SDK install**: `npm install @trigger.dev/sdk`

## Frequently Asked Questions

### Does Trigger.dev have execution time limits?
No. Tasks run until they complete: hours, days, or weeks. There is no timeout to raise or configure, and paused time during waits uses no resources and is not billed. You can cap execution yourself with `maxDuration` per task or per run.

### Do I have to write deterministic code?
No. Tasks are plain async TypeScript. Use `Date.now()`, `Math.random()`, `fetch()`, any npm package. Durability comes from checkpoint-resume snapshots, not replay, so there are no determinism rules to follow and no replay bugs to debug.

### Can I self-host Trigger.dev?
Yes. The full stack (dashboard, orchestrator, workers, CLI) is Apache 2.0 and deploys with Docker Compose or Kubernetes. It is the same core codebase as Cloud. Cloud-only features: warm starts, auto-scaling, checkpoints, dedicated support.

### Does Trigger.dev support Python?
Partially. The platform is TypeScript/JavaScript (Node.js and Bun). Python scripts run via the `pythonExtension` build extension, which installs Python and packages into your deployment. No Go, Java, or Rust support.

### How is Trigger.dev priced?
A monthly plan plus usage. Free: $0/month with $5 of usage credit included. Hobby: $10/month with $10 of credit. Pro: $50/month with $50 of credit. Usage is compute-seconds while tasks actually execute (the default small-1x machine is $0.0000338/second) plus $0.000025 per run. A 10-second task running 100 times per day costs about $1.09/month. Paused tasks use no resources and aren't billed, so long waits are free. Development runs are free. Self-hosting is free under Apache 2.0. Current prices: https://trigger.dev/pricing

### How is Trigger.dev different from Temporal?
Temporal uses event sourcing with replay, which requires deterministic workflow code split into workflows and activities. Trigger.dev uses checkpoint-resume snapshots, so tasks are plain TypeScript functions with no determinism constraints. Full comparison: https://trigger.dev/vs/temporal

### What delivery guarantee does Trigger.dev provide?
At-least-once, with idempotency keys (and configurable TTL) to prevent duplicate work. Stalled runs are detected via heartbeats and retried by the platform.

### Can tasks stream results to my frontend?
Yes. Realtime streams push LLM tokens, progress, and structured data to React hooks (`useRealtimeStream`) and backend subscribers. Realtime updates push run status, metadata, and tags the same way. No polling, and no realtime servers for you to run.

### How do tasks pause for human approval?
Waitpoints. `wait.forToken()` pauses the task and `wait.createToken()` generates a callback URL any external service can POST to. The task checkpoints while waiting, so a week-long approval uses no resources and isn't billed.

### Does Trigger.dev work with Next.js and Vercel?
Yes. Trigger tasks from Route Handlers, Server Actions, or any backend code. The tasks themselves run on Trigger.dev infrastructure, so they aren't subject to serverless function timeouts. The Vercel integration syncs environment variables and supports atomic deploys. Guide: https://trigger.dev/docs/guides/frameworks/nextjs

### How do I get started?
Run `npx trigger.dev@latest init` in your project, write a task (a plain async function), then `npx trigger.dev@latest dev` to run it locally with hot reload. Ship with `npx trigger.dev@latest deploy`. First deploy takes about 5 minutes.

## Use Cases

### AI and LLM Workflows
- Autonomous agents with tool calling and human-in-the-loop
- Prompt chaining and multi-step LLM orchestration
- RAG pipelines with document ingestion and embedding
- Streaming AI responses to the frontend (token-by-token)
- Multi-agent coordination (orchestrator + workers)
- Model evaluation and A/B testing harnesses

### Media Processing
- Video transcoding and editing with FFmpeg
- Audio processing, transcription, and waveform generation
- Image generation, manipulation, and optimization
- PDF generation with LibreOffice or Puppeteer

### Data Processing
- Large CSV / Excel / Parquet processing
- Python data science scripts (Pandas, NumPy) via build extension
- Batch transformations and ETL pipelines
- Database migrations and backfills

### Scheduled Operations
- Cron jobs and recurring tasks
- Multi-tenant dynamic schedules
- Report generation
- Database maintenance and cache warming

### SaaS and Multi-Tenant
- Per-user background jobs
- Tenant-isolated queues with concurrency keys
- Approval workflows with waitpoints
- Usage metering and billing pipelines

## Target Audience

- **TypeScript developers** building production applications
- **AI engineers** deploying agents and LLM workflows
- **SaaS companies** needing multi-tenant background processing
- **Startups** that want managed infrastructure without DevOps headcount
- **Enterprises** needing self-hosting, HIPAA BAA, AWS PrivateLink, SOC 2

## Honest Gaps

- Sandboxed code execution: coming soon, not yet shipped
- No built-in agent memory or state across runs
- No Go, Java, Rust, or other non-TS language support beyond Python via build extension
- No time-based rate limiting (concurrency caps only)
- No native webhook endpoint triggers per task
- No offline local dev
- No agent evaluation / quality scoring built in
- No LLM-specific cost caps per run
- No visual workflow builder

## Customers and Proof Points

- **Magic Patterns**: 200,000+ monthly background jobs. "You set it up once and never have to worry about it again." (Alex Danilowicz)
- **Midday**: Team of 2 scaled to 11,500+ customers. "Trigger.dev was the missing piece." (Pontus Abrahamsson)
- **MagicSchool AI**: "Summarized over a million student interactions in weeks." (Ben Duggan)
- **GovSignals**: FedRAMP High self-hosted deployment. "200% more opportunities and 70% more proposal output." (Conner Aldrich, CTO)
- **Flick.social**: Success rate 87% → 100% after migrating from Temporal. (Andreas Asprou)
- **Papermark**: ~6,000 PDFs / month. (Marc Seitz)
- **Comp AI**: Compliance evidence collection automation. (Lewis Carhart)
- **Pallet, Capy, Tierly, NUMI, HeroUI, Huntr**: AI agent orchestration, deployment pipelines, workflow automation

Full case studies: https://trigger.dev/customers

## Comparisons

- **vs Temporal**: No DSL, no determinism rules. Normal TypeScript instead of workflow functions and activities. https://trigger.dev/vs/temporal
- **vs BullMQ**: Managed infrastructure, durable execution, no Redis to operate. https://trigger.dev/vs/bullmq
- **vs n8n**: Code-first instead of visual workflow builder. https://trigger.dev/vs/n8n
- **vs Inngest, vs Hatchet, vs Restate, vs DBOS**: see https://trigger.dev/vs

## Documentation

- Getting Started: https://trigger.dev/docs
- How It Works: https://trigger.dev/docs/how-it-works
- AI Agents Guide: https://trigger.dev/docs/guides/ai-agents
- Build Extensions: https://trigger.dev/docs/config/extensions/overview
- Realtime: https://trigger.dev/docs/realtime/overview
- Waitpoints: https://trigger.dev/docs/wait-for-token
- Input Streams: https://trigger.dev/docs/tasks/streams
- Self-Hosting: https://trigger.dev/docs/self-hosting/overview
- Management API: https://trigger.dev/docs/management/overview
- MCP Server: https://trigger.dev/docs/mcp-introduction
- Agent Rules: https://trigger.dev/docs/mcp-agent-rules
- Skills: https://trigger.dev/docs/skills
- Examples: https://trigger.dev/docs/examples/overview

## Resources

- Homepage: https://trigger.dev
- GitHub: https://github.com/triggerdotdev/trigger.dev (15,000+ stars, Apache 2.0)
- Pricing: https://trigger.dev/pricing
- Blog: https://trigger.dev/blog
- Changelog: https://trigger.dev/changelog
- Discord: https://trigger.dev/discord
- Customers: https://trigger.dev/customers
- Security: https://trigger.dev/security