Skip to content
STACK IT FAST

Trigger.dev

Curated OSSHybridJob Queue / Dev Tool6-20 people

Audited from github.com/triggerdotdev/trigger.dev

Open-source developer platform for building and deploying durable background jobs, AI agent workflows, and scheduled tasks in TypeScript.

Language
TypeScript
Database
PostgreSQL
Hosting
Docker
License
Apache-2.0
Running for
2 years 2 months
Team
6-20 people

Why this architecture

Trigger.dev eliminates serverless timeout restrictions and queue boilerplate by providing durable, resumable TypeScript workflows.

Tech stack by layer

8 technologies · audited Sep 17, 2026
Frontend & UI
  • RemixWeb application dashboard providing run inspectors, logs, and billing management
Backend & APIs
  • TypeScriptPrimary language powering execution engines, SDK packages, and supervisor daemons
Data & Persistence
  • PrismaType-safe database client and migration manager for primary PostgreSQL schemas
  • PostgreSQLPrimary relational database storing accounts, organizations, environments, and runs
  • ClickHouseColumnar analytics database storing execution traces, logs, and telemetry spans
  • RedisDistributed queues, task rate-limiting, and run state coordination via Redlock
Infrastructure & Deploy
  • DockerContainerized task environments and multi-service development infrastructure
  • TurborepoMonorepo build orchestrator caching package builds and testing pipelines

Trigger.dev architecture diagram

Open SVG
Trigger.dev architecture diagramDashboard → Webapp & API (HTTPS); Your code → Webapp & API (trigger tasks); Webapp & API → Run engine (runs); Run engine → Redis (queue); Run engine → PostgreSQL (run state); Supervisor → Run engine (dequeue); Supervisor → Task containers (start · checkpoint); Task containers → ClickHouse (OTel spans)CLIENTSSERVICESWORKERS & JOBSDATA & STORAGEDashboardRemixYour codetrigger.dev SDKWebapp & APIRemix · PrismaRun enginequeues · waitpointsSupervisorcontainer runsTask containerscheckpoint · restorePostgreSQLruns · orgs (Prisma)ClickHousetraces · logsRedisqueues · Redlockrunsstart · checkpointHTTPStrigger tasksdequeueOTel spansqueuerun state
How the main components of Trigger.dev connect, drawn from the audited repository.
Diagram as text
  • Dashboard (Remix) → Webapp & API (Remix · Prisma): HTTPS
  • Your code (trigger.dev SDK) → Webapp & API (Remix · Prisma): trigger tasks
  • Webapp & API (Remix · Prisma) → Run engine (queues · waitpoints): runs
  • Run engine (queues · waitpoints) → Redis (queues · Redlock): queue
  • Run engine (queues · waitpoints) → PostgreSQL (runs · orgs (Prisma)): run state
  • Supervisor (container runs) → Run engine (queues · waitpoints): dequeue
  • Supervisor (container runs) → Task containers (checkpoint · restore): start · checkpoint
  • Task containers (checkpoint · restore) → ClickHouse (traces · logs): OTel spans

Key architectural decisions

4 decisions
  1. 01

    Decoupled Run Engine with Distributed Redis Queues

    Separates task queueing and execution scheduling into an independent run-engine package backed by Redis streams and Redlock concurrency guards.

  2. 02

    Hybrid Database Architecture with PostgreSQL and ClickHouse

    Uses PostgreSQL via Prisma for transactional entity states while offloading massive timeseries run logs and OpenTelemetry spans to ClickHouse.

  3. 03

    Containerized Task Supervision Daemon

    Implements apps/supervisor to manage ephemeral Node.js and Bun worker containers over Dockerode and Kubernetes client APIs.

  4. 04

    Realtime Checkpointing and Waitpoints

    Enables long-running workflows to pause execution without consuming CPU, resuming automatically on external webhooks or schedule timeouts.

How Trigger.dev is built

How Trigger.dev is structured

Trigger.dev is maintained as a TypeScript monorepo managed with pnpm workspaces and Turborepo. The codebase isolates the user-facing web platform from the distributed execution engines:

  • apps/webapp: The primary management portal built with Remix, exposing user authentication, project settings, API key issuance, and live execution tracing.
  • apps/supervisor: The runtime daemon responsible for orchestrating task execution environments across Docker containers (dockerode) or Kubernetes pods (@kubernetes/client-node).
  • internal-packages/run-engine: The core queue scheduler that coordinates task lifecycles, concurrency limits, retries, and waitpoints using Redis.
  • internal-packages/schedule-engine: Handles cron schedules, intervals, and deferred task triggering via cron-parser.
  • internal-packages/clickhouse: ClickHouse schemas and query builders for high-throughput run telemetry and OTLP spans.
  • packages/core and packages/sdk: Public npm packages providing the client-side workflow definition primitives (task, schedules, wait).

Frontend

The web dashboard in apps/webapp is implemented using Remix and bundled with Vite and esbuild:

  • Run Inspector: Realtime task execution waterfalls displaying step-by-step logs, durations, payload inputs, and error traces.
  • AI Agent Monitoring: Dedicated views for visualizing LLM tool calls, streaming token usage, and agent decisions.
  • Environment Management: Controls for switching between Development, Staging, and Production environments with scoped API keys and webhooks.

Backend & APIs

The backend infrastructure runs Node.js microservices and HTTP workers:

  • Webapp API: Remix server loaders and actions handling REST and GraphQL ingestion for job triggers and telemetry.
  • Run Engine: Processes task queues with fine-grained concurrency control, rate limiting, and distributed locking via Redlock.
  • OTLP Worker: A high-throughput telemetry ingestion service (otlpTransformWorker.ts) parsing OpenTelemetry payloads and writing them directly into ClickHouse.

Data & persistence

Trigger.dev employs a tiered storage architecture:

  • PostgreSQL: Managed with Prisma (@trigger.dev/database), storing users, organizations, project environments, API credentials, and run metadata.
  • ClickHouse: Stores immutable execution spans, stdout/stderr logs, and timeseries metrics, migrated using Goose (pressly/goose).
  • Redis: Coordinates task queues, pub/sub notifications for web dashboard live streams, and in-memory caches.

Realtime / collaboration

Realtime updates are streamed to the frontend dashboard using Server-Sent Events (SSE) and WebSockets via Socket.IO:

  • Developers watching task runs see streaming console logs and step state transitions with sub-second latency.
  • The web app dynamically subscribes to project-specific Redis pub/sub channels to deliver multi-tenant execution events.

Build, test & deploy

The build and deployment lifecycle is managed through Turborepo:

  • TypeScript packages are compiled using tsdown and tsc.
  • Testing is run using Vitest (vitest --no-file-parallelism) alongside Testcontainers (@internal/testcontainers) for spinning up ephemeral PostgreSQL, Redis, and ClickHouse containers.
  • Multi-stage Docker images (docker/Dockerfile) package the webapp and supervisor services using pnpm docker prune strategies.

Self-hosting notes

Trigger.dev provides comprehensive self-hosting support:

  • docker/docker-compose.yml launches the web application alongside PostgreSQL, Redis, and ClickHouse.
  • Production deployments on Kubernetes utilize Helm charts (deploy/helm) to scale worker supervisors and API pods independently.
  • Environment variables configure external authentication (GitHub OAuth), email delivery (Resend, SES), and object storage for large payloads.

What to copy (and what not to)

What to copy:

  • Separating high-volume log and trace ingestion into ClickHouse while keeping relational entity models in PostgreSQL via Prisma.
  • Using waitpoints to pause long-running workflows without tying up active CPU threads or paying for idle compute.
  • Encapsulating task execution runners within containerized supervisor daemons that isolate user code execution.

What not to copy:

  • Complex monorepo internal package hierarchies with circular tooling shims; simpler workspaces can share database clients without multi-tiered internal wrapper libraries.

Sources & repo audit

Audited
Sep 17, 2026
Commit
8067b1f
License
Apache-2.0

Independent analysis of repository at github.com/triggerdotdev/trigger.dev. Spotted an inaccuracy? Use the claim form to request a correction.

Show this stack on your README or website
Tech stack of Trigger.dev
[![Tech stack of Trigger.dev on STACK IT FAST](https://stackitfast.com/badge/trigger-dev.svg)](https://stackitfast.com/project/trigger-dev)

Paste it into your README. It shows your current stack and links to this page.

Use this stack

Scaffold it with your agent

Paste this prompt into Claude Code, Cursor, Windsurf or AGY to start a project with Trigger.dev's architecture.

  1. 1Copy the promptThe full markdown spec, with every layer and decision.
  2. 2Open your AI toolClaude Code, Cursor, Windsurf or Copilot, in a new repo.
  3. 3Paste and scaffoldUse it as the first instruction; review before you ship.
use-this-stack.md · 58 lines · 5.5 KB
# MISSION: Scaffold "Trigger.dev" Production Architecture
You are an expert Senior Staff Software Architect and Full-Stack Engineer. Your mission is to scaffold and implement a production-grade, highly reliable, and modular codebase following the proven architecture of **Trigger.dev**.
---
## 1. PROJECT SPECIFICATIONS & BENCHMARK
- **Reference Architecture**: Trigger.dev
- **What It Does**: Open-source developer platform for building and deploying durable background jobs, AI agent workflows, and scheduled tasks in TypeScript.
- **Domain & Category**: Job Queue / Dev Tool
- **Production Scale**: 6-20 people
- **Development Mode**: HYBRID
- **Architectural Rationale**: Trigger.dev eliminates serverless timeout restrictions and queue boilerplate by providing durable, resumable TypeScript workflows.
- **Live Website Reference**: https://trigger.dev
- **Source Repository**: https://github.com/triggerdotdev/trigger.dev
---
## 2. PRODUCTION TECH STACK
- **Full Stack Array**: TypeScript, Remix, Prisma, PostgreSQL, ClickHouse, Redis, Docker, Turborepo
- **Primary Language(s)**: TypeScript, JavaScript, Shell, CSS, ANTLR, Go Template
- **License of the reference repo**: Apache-2.0
- **Frontend**: Remix — Web application dashboard providing run inspectors, logs, and billing management
- **Backend & APIs**: TypeScript — Primary language powering execution engines, SDK packages, and supervisor daemons
- **Data & persistence**: Prisma — Type-safe database client and migration manager for primary PostgreSQL schemas; PostgreSQL — Primary relational database storing accounts, organizations, environments, and runs; ClickHouse — Columnar analytics database storing execution traces, logs, and telemetry spans; Redis — Distributed queues, task rate-limiting, and run state coordination via Redlock
- **Infrastructure & deploy**: Docker — Containerized task environments and multi-service development infrastructure; Turborepo — Monorepo build orchestrator caching package builds and testing pipelines
---
## 3. KEY ARCHITECTURAL DECISIONS (audited from https://github.com/triggerdotdev/trigger.dev @ 8067b1f)
1. **Decoupled Run Engine with Distributed Redis Queues**: Separates task queueing and execution scheduling into an independent run-engine package backed by Redis streams and Redlock concurrency guards.
2. **Hybrid Database Architecture with PostgreSQL and ClickHouse**: Uses PostgreSQL via Prisma for transactional entity states while offloading massive timeseries run logs and OpenTelemetry spans to ClickHouse.
3. **Containerized Task Supervision Daemon**: Implements apps/supervisor to manage ephemeral Node.js and Bun worker containers over Dockerode and Kubernetes client APIs.
4. **Realtime Checkpointing and Waitpoints**: Enables long-running workflows to pause execution without consuming CPU, resuming automatically on external webhooks or schedule timeouts.
---
## 4. NON-NEGOTIABLE ARCHITECTURAL GUARDRAILS
1. **Monorepo & Modular Separation**:
   - Structure as a Turborepo monorepo with strict package boundaries:
     - `apps/web`: Application UI, routing, layouts, and server endpoints.
     - `packages/ui`: Shared design tokens, CSS variables, and Radix UI primitive components.
     - `packages/db`: Database schemas, client singleton, declarative migrations, and seed scripts.
     - `packages/config`: Shared TypeScript, ESLint, and build configurations.
2. **Strict Type Safety & Zero `any` Policy**:
   - Enable `strict: true`, `noImplicitAny: true`, and `strictNullChecks: true`.
   - Validate ALL external inputs, API request bodies, and query parameters with **Zod** schemas before execution.
3. **Frontend & Rendering Guidelines**:
   - Isolate interactive UI state to leaf components. Keep core pages lightweight and performant.
4. **Design System & Aesthetics**:
   - Keep every color, radius, shadow and font in a single token file (CSS variables) and consume tokens everywhere; never hardcode hex values in components.
   - Prefer crisp 1px borders and one subtle shadow scale over blurry default shadows. Pair one sans-serif for body/headings with one monospace for tags, badges, metrics, and code.
5. **Data Layer & Reliability**:
   - Write declarative schema definitions with foreign keys, composite indexes on queried filters, and automated timestamp triggers.
   - Use connection pooling and prepared statements for serverless database execution.
---
## 5. STEP-BY-STEP SCAFFOLDING ROADMAP
- **Phase 1: Workspace & Root Config**: Initialize package manager, monorepo configuration (`turbo.json`, `tsconfig.base.json`, `package.json`).
- **Phase 2: Database Schema & Client**: Set up the data layer (Prisma, PostgreSQL, ClickHouse, Redis): client, connection pool, models, and migration scripts.
- **Phase 3: Design Tokens & UI Primitives**: Build accessible `Button`, `Input`, `Card`, `Badge`, and layout wrappers inside `packages/ui`.
- **Phase 4: Core Application Routes & Handlers**: Implement primary authentication, user session handling, and application routes.
- **Phase 5: Quality Assurance & Build Verification**: Run `tsc --noEmit`, ESLint, Prettier, and smoke test suites to ensure zero compilation or runtime errors.
---
## 6. EXECUTION INSTRUCTIONS
1. Review all specifications, architectural guardrails, and stack choices above.
2. Present the full monorepo directory tree structure.
3. Systematically generate the complete, production-ready codebase according to the 5-phase roadmap above — starting with the root workspace setup, followed by the database schema, UI design system package, and full-stack application routes until the repository is fully scaffolded and ready to run.
Scaffolded something with this prompt?
Would you pick this stack for a job queue / dev tool project?

Frequently asked about Trigger.dev

How does Trigger.dev handle long-running background tasks without timeouts?

Tasks execute inside dedicated supervisor containers or serverless runtimes that support pausing and checkpointing waitpoints indefinitely.

Why does Trigger.dev use ClickHouse alongside PostgreSQL?

PostgreSQL handles structured relational metadata while ClickHouse ingests high-volume execution telemetry and OpenTelemetry trace spans.

One email a month: new deep dives and stack trends

New source-audited architectures, head-to-head comparisons and the monthly stack report. No spam, unsubscribe anytime.

use-this-stack.md