Durable Execution.
Dead Simple.

Async Await across TypeScript, Python, Rust, and Go. Runs as a single binary on the infrastructure you already have.

Apache 2.0 · Server, SDKs, and tools

Live demo

Claude vs a chess engine — live.

Claude Haiku 4.5 plays black, one durable step per move.

connecting...
White · js-chess-enginedeterministic minimax · L3
Black · Claude Haiku 4.5reasoning agent · one ctx.run per move
Connecting
How this is deployed →

The reliability tax

Failure handling is most of your code.

In a production system, the code that does the actual work is the small part. The rest keeps it alive when something goes wrong — retries, timeouts, idempotency keys, the state machines that remember where a job was when the process died.

By most counts that defensive scaffolding is more than two-thirds of what you ship — and almost none of it is the product. It doesn’t have to be yours to write.

your_program.tswhat you ship

// the product — the actual work

handleOrder()the thing your users came for

// keeping it alive when something goes wrong

retry()
timeout()
idempotencyKey()
stateMachine()
checkpoint()
resumeFrom()
~⅔of what you ship, by most counts — and almost none of it is the product.

Simple to use

You already know how to write this.

No separate workflow language, no orchestration layer to stand up. You write ordinary async functions, and that Async Await is the workflow — the shape of your code is the shape of the execution.

Most of what you’ll write rests on three verbs. A workflow that runs forever is just a while loop — no event-history limit to design around.

// the common surface
ctx.run(step)      // execute a step durably
ctx.rpc(fn)        // call another function
ctx.sleep('30d')   // wait — a second or a month

…and ctx.detached when you want to kick something off and not wait on it.

Simple to reason about

Everything comes down to one promise.

Underneath all of it is a single primitive: the durable promise. Every function call, every HTTP request, every message resolves to one — written down the moment it’s made and settled when it’s done.

When the machine running it crashes, nothing important is lost — the state that drives recovery was never in the process. A new process reads the last promise that was kept and continues from exactly there.

process running
the promise · sustainedthe process · crashes & restarts
The process can die.
The promise is still kept.

The state that drives recovery was never in the process — it was in the promise. A new process reads the last promise that was kept and continues from exactly there.

Runs on your infrastructure

It runs on what you already run.

Resonate runs as a single binary alongside the rest of your stack — one thing to run, not a fleet of services to stand up and keep in sync. Its state lives in your own Postgres, the database you already know how to run and back up.

And because that state is just rows, you can see it: when you want to know what a workflow is doing, you query it with plain SQL.

your stack

▢ resonate — one binary

└─ state → your Postgres

SELECT * FROM promises WHERE id = 'order/42';

A promise is written once and updated when it completes, not on every step — so it stays cost-efficient by design.

A protocol, not a product

A protocol you adopt, not a vendor you depend on.

Durable execution is a protocol, and Resonate is an implementation of it — open source under Apache 2.0. Adopting it means adopting a standard, the way you’d adopt HTTP or SQL: something you build on and can always see inside of.

The specification is written down and open. You can run it, read it, fork it, or build your own.

distributed-async-await.io ↗

the open specification — programming, execution & system models

Open source, no feature gatesFork or build your own48 agent skills
Discord — people building right now