# 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](tidebase-vs-inngest.md)