Open-source durable execution engines still choose whose disk keeps the history

What a durable execution engine records

Two vendors define the term for a living, and both definitions describe the same mechanism. Temporal's page says: "Durable Execution is crash-proof execution." Restate's page goes further: "Durable Execution is a programming paradigm that makes ordinary code resilient to crashes, restarts, and infrastructure failures. A durable execution engine records each step of a function as it runs."

Put the two together and you have one loop. A step finishes. Its result is written down somewhere. Then a crash, a redeploy or a lost machine ends the process, and the next attempt reads the last written result and carries on from that point. What this buys is real. Retries stop needing a hand-written state machine, timers outlive a deploy, and a run moves to another machine without starting over. Neither definition says where the writing happens, though, and neither says who accepts the result at the end. That silence is where the interesting decisions are.

The boundary: your disk or theirs

Six engines in the table store the record in six ordinary places, and where they put it changes what you can do with it.

Temporal writes a workflow's event history to its server. Self-hosted, that history sits in the database you run beside it. On Temporal Cloud it sits in Temporal's storage and is billed as storage. Active storage costs $0.042 per GB-hour and retained storage $0.00105, with actions from $50 per million (Temporal's pricing page).

Restate records each step inside Restate itself and keeps that log beside your service, shipped as a single binary (Restate's repository).

DBOS takes the other side of the line. Its durable workflows run on Postgres, and the library is "entirely contained in this open-source library, there's no additional infrastructure for you to configure or manage" (DBOS Transact).

Inngest puts the state on a server: your functions sync with the Inngest Platform or with a server you run (Inngest's repository). Trigger.dev keeps a run history for each task, and the platform is self-hostable from Docker (Trigger.dev). Hatchet runs as Hatchet Cloud or as a self-hosted install (Hatchet).

A record on your own Postgres moves with a dump, joins your other tables in a query, and outlives the tool that wrote it. A record in a vendor's store moves only when the vendor gives you a way to take it out. You read it through that vendor's API for as long as you keep paying. Neither arrangement is wrong, and they cost different things at different moments. The expensive moment is the one where you change your mind.

Licences, in plain terms

Half the table is a quick read. Temporal, DBOS and Hatchet publish under MIT, and Trigger.dev under Apache-2.0, so in each case you can fork the code and host it yourself. The difference between those two licences is a question for a lawyer on a slow afternoon, not a decision that changes your architecture.

Inngest is the one to read twice. The server and the CLI are under the Server Side Public License, which publishes the code under Apache 2.0 after a delay. All the SDKs are Apache 2.0 today (Inngest's repository). The client libraries are open now. The server's licence is what a team reads before it offers Inngest itself as a service.

Restate is under the Business Source License 1.1, with an additional grant that forbids offering a public Restate platform service. That is not an open-source licence. A team that wants to fork the engine and host it for its own customers needs to read the grant first.

Kortix is open source, and the history an agent produces is a git branch in a repo you already own. That difference matters more here than a licence debate.

Two meters set most of these bills

A per-action meter charges for the record itself. Every step written is a billable event, which rewards coarse steps and punishes a durable call inside a loop. Temporal's Business plan starts at $500 a month with 2.5 million actions and 100 GB of retained storage (pricing), so a team can trade variance for a commitment.

Restate answers with a deployment model instead. Restate's comparison says BYOC runs the binary inside your cloud account. It also claims "up to 10× more cost efficient" than Temporal Cloud, with "a few milliseconds" of overhead per durable step (Restate's comparison, its own claim).

A third shape costs nothing per step: a library like DBOS puts the record in a database you already run and pay for. That is cheap until the table grows, at which point retention becomes a database problem rather than a vendor line item.

When a separate engine is the right call

Some work genuinely needs one. Think of several services in different languages coordinating a single business transaction, timers that run for weeks, or deterministic logic you want to replay against recorded inputs. An existing Temporal deployment that already carries the company's batch jobs is another reason. In those cases the engine does work nothing else in your stack does, and the history belongs wherever the engine keeps it.

The calculation changes when the workload is an agent. Its "step" is a model call that edits twelve files, its failure mode is a bad diff rather than a lost stack frame, and replaying it repeats a bill and a set of edits. A queue can restart that work. It cannot tell you whether the work was right.

Kortix's option, and what it gives up

Kortix is not a durable execution engine, and the distinction should come before any recommendation. It keeps no step journal of its own.

What it has instead is a unit of work that survives interruption by being a branch. A session runs one agent in its own sandbox: the sandbox clones the project repo and works on a new branch whose name is the session id. The agent prompt states the consequence plainly:

The session you're in is an isolated sandbox — an ephemeral branch of this repo …Only what you commit + push survives.

Kortix's docs describe the rest. The agent commits and pushes its session branch, then opens a change request against the project's default branch. A person with the merge permission merges it, and merge is default-deny for agents (Read the docs).

For agent work, that arrangement answers the boundary question in a way an engine cannot. The resume point is a commit in a repo you own. The record a reviewer reads is a diff. When you change tools, the history stays where it was, because it was never the vendor's to hold.

What you give up is real: no replay of arbitrary code, no timers measured in months, no child workflows composing six services. If that is the shape of your work, pick an engine and use the table to see whose disk you are choosing. If your durable concern is an agent whose output a person has to accept, read what durable execution means for an agent, then durable workflows and how this compares with running agents.