Use any database or queue for storage and message transport. Then just write Async Await.
An SDK in your app. One binary beside it. Dead simple.
Protocol · server · SDKs · tools — all Apache 2.0
await ctx.run(chargeCard, order)
Async Await · any Resonate SDK
Postgres
the database or queue you already run
HTTP
the transport you already use
A new server for every stack — that’s Distributed Async Await working. Run something else? Bring your own provider.
The reliability tax
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.
// the product — the actual work
// keeping it alive when something goes wrong
Simple to use
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
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.
The process can die.
The promise is still kept.
Runs on your infrastructure
The core server runs as a single binary alongside the rest of your stack — one service to run, not a fleet to provision and babysit. Its state lives in your own Postgres, the database you already know how to run and back up — and on NATS, an implementation of the protocol runs natively on the broker itself.
When you want to know what a workflow is doing, you ask the CLI. resonate tree prints the whole call graph; resonate promises get inspects a single step. No dashboard to stand up, no proprietary console. And because the state underneath is just rows in your own Postgres, you can always read it directly — it’s yours.
your stack
▢ resonate — one binary└─ state → your Postgres
$ resonate tree 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
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.
the open specification — programming, execution & system models
We value your privacy
We use strictly necessary cookies to run this site. With your consent we also use Google Analytics to understand traffic. We do not load analytics until you choose to allow it. Privacy Policy.