Tidebase vs Trigger.dev
The short answer: Trigger.dev is a deploy-your-tasks platform — you write tasks, it runs them on managed (or self-hosted) infrastructure with no timeouts; Tidebase never runs your code at all. Both give you durable, resumable work; they differ on who owns the runtime.
Tidebase is an open-source checkpoint layer for AI agents: wrap your steps, and failed runs resume from the last safe point — in your own Postgres, without moving execution into a new runtime.
The structural difference
Trigger.dev owns execution. You define tasks in its SDK, deploy them, and the platform provisions the compute, supervises runs, checkpoints execution state, and resumes after failures — that’s the product: long-running background jobs without managing infrastructure, plus queues, schedules, retries, and a realtime API.
Tidebase owns the record and the trigger — never the runtime. Your workflow is a plain function in your own process; Tidebase stores checkpoints, live state, gates, events, and usage in your Postgres, and decides when code should run (queues, cron, recovery webhooks) without ever executing it. Your secrets, dependencies, and compute never leave your infrastructure.
Side by side
| Tidebase | Trigger.dev | |
|---|---|---|
| Who runs your code | You (your app/worker process) | The platform (cloud or self-hosted infra it manages) |
| Long-running safety | Checkpoints in Postgres; something re-invokes; completed steps never repeat | Platform supervises and resumes runs; no timeouts |
| Data location | Your Postgres, next to your app’s tables | Platform’s run store |
| Human approval gates | Built in, durable, exactly-once | Wait-for-token / human-in-the-loop primitives |
| Live run state API for product UIs | Built in (versioned state, SSE) | Realtime API |
| Per-run LLM token/cost ledger | Built in (usage.record) | Build on metadata |
| Queues & cron | Built in, Postgres-backed | Built in |
| Operational footprint | One server + your Postgres | Platform deployment (or use their cloud) |
| Maturity | Self-hosted alpha, opt-in auth | Production, hosted product |
Choose Trigger.dev if
- You want someone else to own the compute for background work — no workers to run, no infrastructure to size.
- You need no-timeout long tasks today on a mature, supported platform.
Choose Tidebase if
- Your code must stay in your own runtime — your VPC, your secrets, your GPU box, your existing worker fleet — and you want durability added around it, not a new place to deploy to.
- You want the run record (state, gates, costs, events) as queryable rows in your own Postgres.
- Your workloads are agent-shaped: approval gates, fanout with idempotent child runs, fork/time-travel state, token ledgers.
The honest tradeoff cuts both ways: Tidebase will never page someone for you or autoscale your tasks — you run the worker. Trigger.dev will, and the price is that execution lives inside its platform.
Repo: https://github.com/BlueprintLabIO/tidebase · See also: Tidebase vs Inngest