Restate: durable execution for services that must finish what they start

The failure Restate is built to remove

Most service code is written as if the process will not die halfway through. A handler charges a card, then calls a shipping API, then writes an order row. If the process is killed between step two and step three, the retry logic you write by hand has to know which steps already happened. Restate's answer is to make the handler itself recoverable: the README describes "Reliable Execution" as a guarantee that code runs to completion, with failures retried using a durable execution mechanism that recovers partial progress and prevents re-executing completed steps.

The audience is narrower than the tagline suggests. Restate is for teams building microservice orchestration, workflows-as-code, event processing, async tasks and stateful actors, and the README lists durable AI agents as a use case. If your problem is a nightly SQL transform, Restate is the wrong shape. The interesting part is that the durable log lives outside your service, so your code stays ordinary code in TypeScript, Java, Kotlin, Python, Go or Rust.

How the server, SDK and durable log fit together

The repository is a Rust workspace with a clear split. The Cargo.toml workspace members include server, lite, cli, crates/*, service-protocol, and tools such as tools/restatectl and tools/restate-doctor. The service-protocol directory and the buf.yaml at the top level indicate the wire contract between the runtime and the SDKs is defined in protobuf, which is why five language SDKs can share one runtime.

At runtime the flow is: your handler runs inside your process, the SDK talks to the Restate server, and the server records execution progress and service state. The README describes the state model as isolated key/value state per entity, persisted together with execution progress, attached to the request on invocation and written back on completion. That attachment model is what makes stateful serverless viable: the runtime does not need your process to hold state between invocations.

Two consequences follow. First, long-running code suspends when it awaits a promise or future and resumes when the promise resolves, so a handler can wait hours without holding a thread. Second, communication between services is exactly-once, covering request-response, one-way messages and scheduled tasks. The README also notes that OpenTelemetry traces are generated automatically for handler interactions, which matters because a durable execution engine that you cannot observe is hard to debug.

Installing the server and CLI, then running a first invocation

The README offers pre-built binaries of the CLI and the server for macOS and Linux, and points to the Quickstart and the local development page for the full walkthrough. The server installs three ways. Homebrew:

brew install restatedev/tap/restate-server

Or through npx, which pulls the server package without a global install:

npx @restatedev/restate-server

Or as a container, exposing the three ports the README uses:

docker run --rm -p 8080:8080 -p 9070:9070 -p 9071:9071 \
    --add-host=host.docker.internal:host-gateway docker.restate.dev/restatedev/restate:latest

The CLI is separate and also has three routes: brew install restatedev/tap/restate, npm install --global @restatedev/restate, or npx @restatedev/restate. The README also points to the release page and the download page for binaries if you prefer not to use a package manager.

Once the server is up, the documented next step is the Tour of Restate, which walks through the core features. The README does not spell out the registration command or the exact handler invocation syntax in the text shown, so follow the Quickstart for those specifics rather than guessing flags. What you should expect from the container command is a server listening on the three mapped ports, with the CLI able to talk to it for introspection and state inspection.

Where Restate will disappoint you

The README is candid about versioning and silent about several operational questions. It states that upgrading from an x.y release to x.(y+1) is safe without manual data migration because Restate performs the migration automatically. That is a strong claim, and it is scoped: it says nothing about jumping two minor versions, and it says nothing about downgrades. The README does not document rollback. If your team needs a tested downgrade path, that is a gap you have to close yourself before production.

SDK compatibility is deliberately delegated. The README points to a version matrix in each SDK repository rather than publishing one table here, which means a server upgrade and an SDK upgrade are two independent decisions that you have to reconcile by reading five separate READMEs. That is a real coordination cost for polyglot teams.

The busier limitation is architectural. Durable execution is not free: every handler step that must survive a crash has to be recorded, and the README's own description of state attachment and write-back implies the runtime sits in the request path. The repository includes a benchmarks directory and tools/bifrost-benchpress, which suggests the maintainers measure this, but the README makes no latency claim, and you should not assume one. Finally, Restate is a runtime you operate. If you want a managed control plane, the README does not describe one, and the cloud-tunnel-client crate in the workspace is not explained in the text shown.

Restate compared with Temporal, and with Airflow

The most common comparison is with Temporal, and the difference is in where your code lives. Temporal's model centres on writing workflow definitions against its SDK, with the workflow and activity split as the core organizing idea. Restate's README frames the primitives differently: reliable execution, reliable communication, durable promises and timers, consistent state, suspending user code, and observability. The pitch is that you keep writing ordinary handlers and the runtime adds durability around them, rather than restructuring the program into workflow and activity types. Whether that is better depends on how much you want the runtime to shape your code.

Against Airflow the distinction is sharper. Airflow schedules DAGs of tasks, usually over data, and its unit of work is a task in a graph. Restate's unit of work is a service handler with key/value state, and its concerns are exactly-once delivery, promises, timers and recovery of partial progress. If your job is "run these 40 transforms at 02:00 and retry failures," Airflow is the natural tool and Restate is not. If your job is "this order must be charged, shipped and recorded exactly once, and it may wait three days for a webhook," the reverse holds. The README positions Restate for event processing and async tasks, not for batch scheduling.

Licence, maintenance and the upgrade bill

The workspace Cargo.toml declares license = "BUSL-1.1" for the workspace package, while the repository metadata reports NOASSERTION. Those two signals disagree in form, and BUSL-1.1 is a source-available licence rather than an OSI open source licence. The README itself does not discuss licensing or its commercial terms. If your organization has a policy against source-available licences, that policy applies here, and the specific grant and its change date are in the LICENSE file, not in the README. This is not legal advice; read LICENSE and, if the deployment is commercial, get counsel to read it.

On maintenance, the repository is not archived, and the last push was on 2026-09-22, with releases v1.7.12 and v1.7.11 both dated 2026-09-22 and v1.7.10 on 2026-09-14. That is a tight release cadence. The workspace version string is 1.8.0-dev, so a 1.8 line is in progress on main.

The upgrade cost is mostly the SDK matrix. Because the README promises automatic data migration within a minor line, the server side is the cheap half. The expensive half is keeping five SDK version constraints aligned with the server you run, and the README pushes that work to each SDK repository rather than centralizing it.

Editorial conclusion

Adopt Restate when you already write handlers in one of the five supported SDKs and the failure you keep hitting is a half-finished multi-step operation, not a missing cron schedule. Skip it if your work is a batch DAG over a data warehouse, or if you need a permissively licensed runtime, since the workspace declares BUSL-1.1. Before committing, verify the SDK version matrix for your language, confirm the licence terms for your deployment model, and check whether your platform can run the server binary or container.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. restatedev/restate on GitHub