Tidebase vs Cloudflare Workflows
The short answer: Cloudflare Workflows is durable execution inside Cloudflare’s runtime — your steps run as Workers on their edge; Tidebase is durable state outside any runtime — your steps run wherever your code already runs. The APIs look like cousins (step.do(...) vs run.step(...)); the deployment models are opposites.
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
Cloudflare Workflows owns the runtime. A workflow is a Worker class deployed to Cloudflare; the platform persists each step.do result, sleeps for days without billing compute, retries steps, and resumes after failures. It’s genuinely good durable execution — provided your code is a Worker: V8 isolate limits, Workers-compatible dependencies, Cloudflare as the home for execution state.
Tidebase owns no runtime. Your workflow is a plain function in your own Node or Python process — your VPC, your GPU box, your existing containers, any dependency that installs. Tidebase stores checkpoints, live state, gates, events, and usage in your Postgres, triggers re-invocation via queues/cron/webhooks, and never executes anything.
Side by side
| Tidebase | Cloudflare Workflows | |
|---|---|---|
| Where steps execute | Your processes, any runtime | Cloudflare Workers (V8 isolates) |
| Where durable state lives | Your Postgres | Cloudflare’s infrastructure |
| Dependency constraints | None — it’s your process | Workers-compatible only |
| Long sleeps/waits | Gates and queues park in Postgres; no process held | First-class step.sleep, very cheap |
| Human approval gates | Built in, durable, exactly-once, webhook channels | Build with events/waits |
| Live run state for product UIs | Versioned state + SSE, queryable rows | Inspect via API/dashboard |
| Per-run LLM cost ledger | Built in | Build yourself |
| Vendor coupling | None (Apache-2.0, self-hosted) | Cloudflare |
| Maturity | Self-hosted alpha, opt-in auth | GA on a major platform |
Choose Cloudflare Workflows if
- You’re already deployed on Workers and want durability with zero additional infrastructure — it’s the native answer there.
- Long timer-driven flows (sleep three days, then act) at minimal cost are the core need.
Choose Tidebase if
- Your agent code can’t live in a Worker — heavy Python deps, local models, long CPU-bound work, private network access — or you don’t want execution state living in a vendor’s platform.
- You want checkpoints, approvals, and costs in your own Postgres, joinable against your application tables.
- One durability layer should span heterogeneous runtimes: the same run record whether the step ran in Node, Python, or a box in your office.
The honest tradeoff: Cloudflare runs your steps and bills you nearly nothing while they sleep; Tidebase runs nothing, so a worker, webhook, or queue of yours must re-invoke — Tidebase’s guarantee is that doing so is always safe.
Repo: https://github.com/BlueprintLabIO/tidebase · See also: Tidebase vs DBOS and Restate