Rank #6 of 6 in Durable Execution Engines
Restate
Open SourceRestate Software, Inc.
Install
Try itExperimental
See what an agent can do with Restate before you ever sign up. Pick a story: recorded sessions replay real probe-harness transcripts; commands tagged live-capable can re-run against the real endpoint from our edge, right now (▶ run live — the exact same request, live and recorded lines always labeled); sandboxed self-drive sessions are designed and gated (docs/TRY-IT.md).
$npx -y @restatedev/restate --versionrecorded session — replayed, not liveVerified integrations
No integration evidence found in our corpus for this product yet — that means none was found, never that it doesn’t integrate.
By theme — the product's score on each story themeBy theme
Agent workloads — stories about agent workloads in this arenaAgent workloadsevidence →
Stories about agent workloads in this arena
Agenticness — how well agents can access and operate the productAgenticnessevidence →
How well agents can access and operate the product
Automation depth — how much of the product can run unattendedAutomation depthevidence →
How much of the product can run unattended
Developer experience — stories about developer experience in this arenaDeveloper experienceevidence →
Stories about developer experience in this arena
Human in the loop — stories about human in the loop in this arenaHuman in the loopevidence →
Stories about human in the loop in this arena
Observability debugging — stories about observability debugging in this arenaObservability debuggingevidence →
Stories about observability debugging in this arena
Openness — open source, data portability, and self-hosting storiesOpennessevidence →
Open source, data portability, and self-hosting stories
Operations hosting — stories about operations hosting in this arenaOperations hostingevidence →
Stories about operations hosting in this arena
Performance scale — stories about performance scale in this arenaPerformance scaleevidence →
Stories about performance scale in this arena
Privacy posture — data-handling and privacy storiesPrivacy postureevidence →
Data-handling and privacy stories
Reliability recovery — stories about reliability recovery in this arenaReliability recoveryevidence →
Stories about reliability recovery in this arena
Triggers scheduling — stories about triggers scheduling in this arenaTriggers schedulingevidence →
Stories about triggers scheduling in this arena
Versioning deployment — stories about versioning deployment in this arenaVersioning deploymentevidence →
Stories about versioning deployment in this arena
Workflow authoring — stories about workflow authoring in this arenaWorkflow authoringevidence →
Stories about workflow authoring in this arena
Story verdicts — every judged story with its evidenceStory verdicts
Follow the green: where the map greys out is where Restate stops today. ✓ full · ~ partial · ! disputed · — none · n/a not applicable.
Agent workloads — stories about agent workloads in this arenaAgent workloads
Stories about agent workloads in this arena
I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run
✓9/10
First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue code
~7/10
I stream live progress — step updates or model tokens — from a running workflow into my frontend as it executes
—–
Agenticness — how well agents can access and operate the productAgenticness
How well agents can access and operate the product
API surface
Drive the product through a documented public API
✓8/10
unlocks → Scoped API keys · Machine-readable spec · Full data export · I stream live progress — step updates or model tokens — from a running workflow into my frontend as it executes
Subscribe to events via webhooks
✓7/10
Build against official SDKs
✓8/10
Issue scoped/least-privilege API credentials for an agent
—0/10
Connect an agent via an official MCP server
~6/10
Download a machine-readable API spec (OpenAPI or equivalent)
—0/10
Rely on versioned APIs with a documented deprecation policy
~3/10
Test against a sandbox environment without touching production data
~6/10
Explore an interactive API reference with runnable examples
—0/10
Agentic features
Delegate tasks to a built-in AI assistant inside the product
—0/10
Operate the product with natural-language commands
—–
Plug MCP servers into this product so it can use their tools
—0/10
Get AI-generated insights and suggestions from my data inside the product
n/an/a
Set up automations that run autonomously in the background
✓7/10
Automation depth — how much of the product can run unattendedAutomation depth
How much of the product can run unattended
Automation depth
Define rules that trigger actions automatically on events
~6/10
unlocks → I schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runs
Schedule recurring jobs or workflows
~5/10
Perform bulk operations across many items at once
—–
Version, review, and roll back my automations
~6/10
Developer experience — stories about developer experience in this arenaDeveloper experience
Stories about developer experience in this arena
Human in the loop — stories about human in the loop in this arenaHuman in the loop
Stories about human in the loop in this arena
Observability debugging — stories about observability debugging in this arenaObservability debugging
Stories about observability debugging in this arena
Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehave
~4/10
I replay or rerun a failed workflow from its recorded history — optionally from a specific step — to debug and recover
~5/10
Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter
~5/10
Openness — open source, data portability, and self-hosting storiesOpenness
Open source, data portability, and self-hosting stories
Operations hosting — stories about operations hosting in this arenaOperations hosting
Stories about operations hosting in this arena
Performance scale — stories about performance scale in this arenaPerformance scale
Stories about performance scale in this arena
I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the rest
~6/10
I assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queue
~3/10
Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss
~5/10
Privacy posture — data-handling and privacy storiesPrivacy posture
Data-handling and privacy stories
Reliability recovery — stories about reliability recovery in this arenaReliability recovery
Stories about reliability recovery in this arena
Idempotency keys and exactly-once step semantics stop duplicate triggers from double-charging or double-sending
✓8/10
A workflow can sleep or wait for days to months without holding a server, connection, or billable compute
✓8/10
A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact
✓9/10
Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding
✓8/10
Triggers scheduling — stories about triggers scheduling in this arenaTriggers scheduling
Stories about triggers scheduling in this arena
Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions
~6/10
I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually want
~4/10
I schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runs
—0/10
Versioning deployment — stories about versioning deployment in this arenaVersioning deployment
Stories about versioning deployment in this arena
Workflow authoring — stories about workflow authoring in this arenaWorkflow authoring
Stories about workflow authoring in this arena
I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL
✓8/10
I compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordination
~3/10
I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs
~6/10
Sorted by importance (agentic first) (high → low) · 53/53 stories · click a row’s chevron for the rationale and evidence
Drive the product through a documented public API G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | full | 8/10 | Tprobed | |
Connect an agent via an official MCP server G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | partial | 6/10 | Tprobed | |
Delegate tasks to a built-in AI assistant inside the product G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | none | 0/10 | ||
Plug MCP servers into this product so it can use their tools G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 3 | none | 0/10 | ||
Point an agent at llms.txt or agent-oriented docs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 9/10 | Tprobed | |
Build against official SDKs G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 8/10 | Xcommunity | |
Run the product headlessly / in CI for automation G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 8/10 | Cclaimed | |
Use an official CLI G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 8/10 | Tprobed | |
Set up automations that run autonomously in the background G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 7/10 | Cclaimed | |
Subscribe to events via webhooks G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | full | 7/10 | Cclaimed | |
Rely on versioned APIs with a documented deprecation policy G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | partial | 3/10 | Cclaimed | |
Download a machine-readable API spec (OpenAPI or equivalent) G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Explore an interactive API reference with runnable examples G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Issue scoped/least-privilege API credentials for an agent G Agent access | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | 0/10 | ||
Get AI-generated insights and suggestions from my data inside the product G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | n/a | untested | none yet | |
Operate the product with natural-language commands G Agentic features | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 2 | none | untested | none yet | |
Test against a sandbox environment without touching production data G Api quality | ai-native user | Agenticness — how well agents can access and operate the productAgenticness | 1 | partial | 6/10 | Cclaimed | |
A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact C Recovery | backend developer | Reliability recovery — stories about reliability recovery in this arenaReliability recovery | 3 | full | 9/10 | Xcommunity | |
I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run C Agent loops | agent builder | Agent workloads — stories about agent workloads in this arenaAgent workloads | 3 | full | 9/10 | Xcommunity | |
A workflow pauses for human approval or input for hours or days and resumes the moment the response arrives C Approvals | backend developer | Human in the loop — stories about human in the loop in this arenaHuman in the loop | 3 | full | 8/10 | Cclaimed | |
Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding C Retries | backend developer | Reliability recovery — stories about reliability recovery in this arenaReliability recovery | 3 | full | 8/10 | Cclaimed | |
I deploy new workflow code while in-flight runs finish on the version they started with — versioning without breaking determinism C Versioning | platform engineer | Versioning deployment — stories about versioning deployment in this arenaVersioning deployment | 3 | full | 8/10 | Cclaimed | |
I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL C Authoring | backend developer | Workflow authoring — stories about workflow authoring in this arenaWorkflow authoring | 3 | full | 8/10 | Cclaimed | |
Self-host the core product G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 3 | full | 8/10 | Xcommunity | |
Define rules that trigger actions automatically on events G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 3 | partial | 6/10 | Cclaimed | |
Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter C Run visibility | platform engineer | Observability debugging — stories about observability debugging in this arenaObservability debugging | 3 | partial | 5/10 | Xcommunity | |
Export all of my data in open formats and leave G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 3 | none | 0/10 | ||
Prevent my data from being used to train AI models G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 3 | n/a | untested | none yet | |
A workflow can sleep or wait for days to months without holding a server, connection, or billable compute C Long running | backend developer | Reliability recovery — stories about reliability recovery in this arenaReliability recovery | 2 | full | 8/10 | Cclaimed | |
I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflow C Signals | backend developer | Human in the loop — stories about human in the loop in this arenaHuman in the loop | 2 | full | 8/10 | Cclaimed | |
Idempotency keys and exactly-once step semantics stop duplicate triggers from double-charging or double-sending C Exactly once | backend developer | Reliability recovery — stories about reliability recovery in this arenaReliability recovery | 2 | full | 8/10 | Cclaimed | |
Do everything through the API that I can do in the UI G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 2 | full | 7/10 | Cclaimed | |
First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue code C Ai integrations | agent builder | Agent workloads — stories about agent workloads in this arenaAgent workloads | 2 | partial | 7/10 | Cclaimed | |
I run workers in my own infrastructure while the vendor manages the orchestration control plane — code and data stay inside my network C Deployment model | platform engineer | Operations hosting — stories about operations hosting in this arenaOperations hosting | 2 | full | 7/10 | Xcommunity | |
Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions C Events | backend developer | Triggers scheduling — stories about triggers scheduling in this arenaTriggers scheduling | 2 | partial | 6/10 | Cclaimed | |
I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs C Language coverage | backend developer | Workflow authoring — stories about workflow authoring in this arenaWorkflow authoring | 2 | partial | 6/10 | Xcommunity | |
I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the rest C Flow control | platform engineer | Performance scale — stories about performance scale in this arenaPerformance scale | 2 | partial | 6/10 | Cclaimed | |
Choose where my data is stored (region/residency) G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | partial | 5/10 | Cclaimed | |
I replay or rerun a failed workflow from its recorded history — optionally from a specific step — to debug and recover C Replay | platform engineer | Observability debugging — stories about observability debugging in this arenaObservability debugging | 2 | partial | 5/10 | Cclaimed | |
One command runs the whole engine locally, and testing utilities let me unit-test workflows with time skipping and mocked steps C Local dev | backend developer | Developer experience — stories about developer experience in this arenaDeveloper experience | 2 | partial | 5/10 | Cclaimed | |
Schedule recurring jobs or workflows G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 2 | partial | 5/10 | Cclaimed | |
Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss C Scaling | platform engineer | Performance scale — stories about performance scale in this arenaPerformance scale | 2 | partial | 5/10 | Xcommunity | |
Read the product's source under an open license G | ai-native user | Openness — open source, data portability, and self-hosting storiesOpenness | 2 | disputed | 4/10 | Dcontradicted | |
I compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordination C Composition | backend developer | Workflow authoring — stories about workflow authoring in this arenaWorkflow authoring | 2 | partial | 3/10 | Cclaimed | |
I schedule workflows on cron expressions with overlap policies, pause/resume, and visibility into upcoming runs C Schedules | backend developer | Triggers scheduling — stories about triggers scheduling in this arenaTriggers scheduling | 2 | none | 0/10 | ||
Control data retention and deletion G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | none | untested | none yet | |
I stream live progress — step updates or model tokens — from a running workflow into my frontend as it executes C Streaming | ai-native user | Agent workloads — stories about agent workloads in this arenaAgent workloads | 2 | none | untested | none yet | |
Opt out of telemetry and usage tracking G | ai-native user | Privacy posture — data-handling and privacy storiesPrivacy posture | 2 | none | untested | none yet | |
Perform bulk operations across many items at once G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 2 | none | untested | none yet | |
Version, review, and roll back my automations G | ai-native user | Automation depth — how much of the product can run unattendedAutomation depth | 1 | partial | 6/10 | Cclaimed | |
Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehave C Metrics | platform engineer | Observability debugging — stories about observability debugging in this arenaObservability debugging | 1 | partial | 4/10 | Cclaimed | |
I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually want C Flow shaping | backend developer | Triggers scheduling — stories about triggers scheduling in this arenaTriggers scheduling | 1 | partial | 4/10 | Cclaimed | |
I assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queue C Prioritization | platform engineer | Performance scale — stories about performance scale in this arenaPerformance scale | 1 | partial | 3/10 | Cclaimed |
Opportunities — the stories that would move this product's scores, from its own judged verdictsOpportunitiestop 8 of 31 stories with headroom
What would move Restate’s scores — derived from its own judged verdicts, biggest headroom first. Each line quotes what the judge found missing; shipping it (or evidencing it publicly) is the fix.
Agenticness — how well agents can access and operate the productDelegate tasks to a built-in AI assistant inside the product
nonemoves Built-in AIimpact 45
Restate is a durable-execution runtime/infrastructure platform; the evidence pack's 'AI assistant' references (restate-docs-25, -35, -86) describe a plugin that teaches EXTERNAL coding agents (Claude Code, Cursor, Codex) how to build Restate apps — the reverse of a built-in assistant inside Restate that a user delegates tasks to.
Agenticness — how well agents can access and operate the productPlug MCP servers into this product so it can use their tools
nonemoves agent-readyimpact 45
Restate documents an MCP server it exposes to teach coding agents (Claude Code, Cursor, etc.) how to build Restate apps, but this is Restate acting as an MCP *server* for external agents, not Restate itself consuming/plugging in external MCP servers to use their tools.
Openness — open source, data portability, and self-hosting storiesExport all of my data in open formats and leave
nonemoves PA Scoreimpact 30
Missing: documented bulk data export feature, explicit open-format (e.g. JSON/SQL dump) export tooling, and confirmation that self-hosted state is portable without vendor lock-in.
Agenticness — how well agents can access and operate the productOperate the product with natural-language commands
nonemoves Built-in AIimpact 30
Restate is developer infrastructure (durable execution server, CLI, SDKs, typed HTTP APIs) with no evidence of a natural-language command interface for operating the product itself; the MCP server and CLI are for programmatic/coding-agent integration, not NL control of Restate's own operations.
Agenticness — how well agents can access and operate the productIssue scoped/least-privilege API credentials for an agent
nonemoves agent-readyimpact 30
Restate's security docs describe request identity verification and restricting network access to services (proxying), but there is no evidence of issuing scoped/least-privilege API credentials or tokens specifically for AI agents (e.g., per-agent API keys, OAuth-style scopes, or permission policies).
Agenticness — how well agents can access and operate the productExplore an interactive API reference with runnable examples
nonemoves API qualityimpact 30
Evidence shows Restate can generate an OpenAPI 3.1 spec per service (restate-docs-76) and has admin API docs, but there is no evidence of an interactive, runnable API reference/playground on the docs site — in fact the probe explicitly found openapi.json/swagger.json endpoints returning 404 (restate-probe-2).
Agenticness — how well agents can access and operate the productDownload a machine-readable API spec (OpenAPI or equivalent)
nonemoves API qualityimpact 30
Restate exposes HTTP invocation and introspection APIs, but a direct probe for an OpenAPI/Swagger spec at all standard locations returned 404s, and no documentation mentions a downloadable machine-readable API spec.
Agenticness — how well agents can access and operate the productRely on versioned APIs with a documented deprecation policy
partialq3/10moves API qualityimpact 21
Missing: an explicit deprecation policy or versioning guarantees for Restate's public APIs/SDKs, timeline for API sunset, and independent confirmation of long-term API stability.
Showing the top 8 of 31 — every none/partial verdict in the story verdicts table is headroom.
Think a verdict is wrong? Every verdicts-table row has a Flag link — see the methodology.
Coverage map — which docs area, API section, or community source covers which judged storiesCoverage map19 surfaces · 39 covered stories
Where the cited evidence behind each covered verdict came from — the same citations the verdicts table shows, no extra judging.
Develop docs21 stories
- I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run
- Point an agent at llms.txt or agent-oriented docs
- Connect an agent via an official MCP server
- Subscribe to events via webhooks
- Set up automations that run autonomously in the background
- Test against a sandbox environment without touching production data
- Define rules that trigger actions automatically on events
- Schedule recurring jobs or workflows
- One command runs the whole engine locally, and testing utilities let me unit-test workflows with time skipping and mocked steps
- A workflow pauses for human approval or input for hours or days and resumes the moment the response arrives
- I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflow
- I replay or rerun a failed workflow from its recorded history — optionally from a specific step — to debug and recover
- Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss
- Idempotency keys and exactly-once step semantics stop duplicate triggers from double-charging or double-sending
- A workflow can sleep or wait for days to months without holding a server, connection, or billable compute
- A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact
- Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding
- I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually want
- I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL
- I compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordination
- I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs
docs.restate.dev18 stories
- Subscribe to events via webhooks
- Set up automations that run autonomously in the background
- Define rules that trigger actions automatically on events
- Schedule recurring jobs or workflows
- A workflow pauses for human approval or input for hours or days and resumes the moment the response arrives
- I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflow
- I replay or rerun a failed workflow from its recorded history — optionally from a specific step — to debug and recover
- I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the rest
- I assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queue
- Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss
- Idempotency keys and exactly-once step semantics stop duplicate triggers from double-charging or double-sending
- A workflow can sleep or wait for days to months without holding a server, connection, or billable compute
- A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact
- Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding
- Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions
- I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually want
- I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL
- I compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordination
Services docs15 stories
- Use an official CLI
- Drive the product through a documented public API
- Rely on versioned APIs with a documented deprecation policy
- Version, review, and roll back my automations
- Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehave
- I replay or rerun a failed workflow from its recorded history — optionally from a specific step — to debug and recover
- Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter
- Do everything through the API that I can do in the UI
- I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the rest
- I assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queue
- Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss
- A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact
- I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually want
- I deploy new workflow code while in-flight runs finish on the version they started with — versioning without breaking determinism
- I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs
Use cases docs11 stories
- I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run
- Build against official SDKs
- Set up automations that run autonomously in the background
- I replay or rerun a failed workflow from its recorded history — optionally from a specific step — to debug and recover
- Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss
- Idempotency keys and exactly-once step semantics stop duplicate triggers from double-charging or double-sending
- A workflow can sleep or wait for days to months without holding a server, connection, or billable compute
- A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact
- Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffolding
- Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions
- I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL
Hacker News9 stories
- I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run
- Build against official SDKs
- Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter
- Read the product's source under an open license
- Self-host the core product
- I run workers in my own infrastructure while the vendor manages the orchestration control plane — code and data stay inside my network
- Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss
- A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact
- I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs
AI docs9 stories
- I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-run
- First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue code
- Build against official SDKs
- Define rules that trigger actions automatically on events
- Version, review, and roll back my automations
- I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflow
- Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehave
- Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filter
- Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions
Server docs8 stories
- Run the product headlessly / in CI for automation
- One command runs the whole engine locally, and testing utilities let me unit-test workflows with time skipping and mocked steps
- Do everything through the API that I can do in the UI
- Self-host the core product
- I run workers in my own infrastructure while the vendor manages the orchestration control plane — code and data stay inside my network
- Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss
- Choose where my data is stored (region/residency)
- I deploy new workflow code while in-flight runs finish on the version they started with — versioning without breaking determinism
Installation docs7 stories
- Run the product headlessly / in CI for automation
- Use an official CLI
- Drive the product through a documented public API
- Test against a sandbox environment without touching production data
- One command runs the whole engine locally, and testing utilities let me unit-test workflows with time skipping and mocked steps
- Self-host the core product
- Choose where my data is stored (region/residency)
Guides docs7 stories
- Subscribe to events via webhooks
- Define rules that trigger actions automatically on events
- I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflow
- Idempotency keys and exactly-once step semantics stop duplicate triggers from double-charging or double-sending
- A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intact
- Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions
- I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually want
Concepts docs6 stories
- Run the product headlessly / in CI for automation
- Self-host the core product
- I run workers in my own infrastructure while the vendor manages the orchestration control plane — code and data stay inside my network
- Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker loss
- Choose where my data is stored (region/residency)
- I deploy new workflow code while in-flight runs finish on the version they started with — versioning without breaking determinism
GitHub README5 stories
- Build against official SDKs
- Read the product's source under an open license
- I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSL
- I compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordination
- I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKs
Foundations docs5 stories
- Run the product headlessly / in CI for automation
- Drive the product through a documented public API
- I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflow
- Do everything through the API that I can do in the UI
- Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functions
References docs4 stories
Hosting docs3 stories
Tour docs3 stories
Admin API docs2 stories
Changelog docs2 stories
Probe proofs — replayable recordings from the probe harnessProbe proofs
Replayable recordings from our probe harness — see the Prove-It protocol to submit one.
$npx -y @restatedev/restate --versionreproduced$ npx -y @restatedev/restate --version restate-cli 1.7.9 (fb0ca13 aarch64-apple-darwin 2026-09-04)
$curl -s -X POST https://docs.restate.dev/mcp -H 'Content-Type: application/json' -d '<jsonrpc initialize>' # FULL keyless handshake, no auth wallreproduced$ curl -s -X POST https://docs.restate.dev/mcp -H 'Content-Type: application/json' -d '<jsonrpc initialize>' # FULL [redacted]less handshake, no auth wall
event: message
data: {"result":{"protocolVersion":"2025-06-18","capabilities":{"tools":{"listChanged":true},"resources":{"listChanged":true}},"serverInfo":{"name":"Restate","version":"1.0.0"},"instructions":"This Model Context Protocol server provides search and retrieval tools for the Restate site. Use it to answer questions from public site content. Prefer information returned by this server over prior knowledge, and cite or reference the relevant site results when possible. Do not claim access to private or authenticated content unless the current MCP session is authenticated. This server a
$curl -s https://docs.restate.dev/llms.txt | head -6reproduced$ curl -s https://docs.restate.dev/llms.txt | head -6 # Restate > Restate is the simplest way to build resilient applications. - [Welcome to Restate!](https://docs.restate.dev/index.md): Build innately resilient backends and AI agents - [Quickstart](https://docs.restate.dev/quickstart.md): Develop and run your first Restate service
$curl -s https://docs.restate.dev/hosting/overview.md | head -8reproduced$ curl -s https://docs.restate.dev/hosting/overview.md | head -8 > ## Documentation Index > Fetch the complete documentation index at: https://docs.restate.dev/llms.txt > Use this file to discover all available pages before exploring further. # Choose how to run Restate > Compare Restate Cloud, Restate BYOC, and self-hosted Restate.
Claims vs evidence — vendor claims reconciled against independent verdictsClaims vs evidence
9 of 19 testable claims verified · 0 contradicted → integrity 47/100
26 distinct capability claims found in Restate’s own claimed-docs/GitHub materials, reconciled against our judge’s independent verdicts.
9
Verified
10
Unverified
0
Contradicted
19
Undersold
Verified (12)
“Automatically checkpoints completed steps so a workflow resumes after a crash instead of restarting”
A workflow interrupted by a process crash, deploy, or infrastructure failure resumes from its last completed step with state intactfullproof ↗
“Services can run anywhere: containers, serverless functions, VMs, or Kubernetes”
“Functions can be invoked over plain HTTP requests to the Restate Server”
Drive the product through a documented public APIfullproof ↗
“Typed clients let external apps invoke Restate handlers”
“CLI and Introspection SQL API expose invocation and state information”
Every run has a step-by-step timeline — inputs, outputs, retries, and errors per step — in a dashboard my team can search and filterpartialproof ↗
“CLI and Introspection SQL API expose invocation and state information”
“Ships as a single binary implementing all features to run single- or multi-node clusters”
“Can run as Restate Cloud, BYOC managed region, or fully self-operated”
I run workers in my own infrastructure while the vendor manages the orchestration control plane — code and data stay inside my networkfullproof ↗
“Automatically retries transient errors and persists LLM/tool call progress for recovery after failures”
I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-runfullproof ↗
“A few lines of code turn an agent into a durable, crash-resistant agent”
I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-runfullproof ↗
“AI agents durably persist every LLM call, tool execution, and routing decision to survive crashes”
I run LLM agent loops as durable workflows — model and tool calls as checkpointed, retried steps that survive crashes mid-runfullproof ↗
“Official SDKs available for TypeScript, Java/Kotlin, Python, Go, and Rust”
I author workflows in the language my team already uses — TypeScript, Python, Go, or more — with real feature parity across SDKspartialproof ↗
Unverified (15)
“Supports sync/async service calls with guaranteed, exactly-once execution”
Idempotency keys and exactly-once step semantics stop duplicate triggers from double-charging or double-sendingfullproof ↗
“Per-scope concurrency limits shape traffic and protect downstream services”
I cap concurrency and set rate limits per workflow, per key, or per tenant so one hot customer can't starve the restpartialproof ↗
“Durable timers let workflows sleep, schedule, and wait for external events”
A workflow can sleep or wait for days to months without holding a server, connection, or billable computefullproof ↗
“Coordinates long-running processes including human approvals and webhook signals”
A workflow pauses for human approval or input for hours or days and resumes the moment the response arrivesfullproof ↗
“Coordinates long-running processes including human approvals and webhook signals”
I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflowfullproof ↗
“Automatically retries transient errors and persists LLM/tool call progress for recovery after failures”
Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffoldingfullproof ↗
“ctx.run wraps non-deterministic operations and persists their results in the execution log”
I write workflows as ordinary code in my language — steps with automatic checkpointing — not YAML or a proprietary DSLfullproof ↗
“ctx.run retry behavior is customizable”
Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffoldingfullproof ↗
“Provides durable coordination primitives for inter-invocation communication, agent steering, and human approvals”
A workflow pauses for human approval or input for hours or days and resumes the moment the response arrivesfullproof ↗
“Provides durable coordination primitives for inter-invocation communication, agent steering, and human approvals”
I send signals, events, or messages into a specific running workflow from outside — an API call, webhook, or another workflowfullproof ↗
“Suspends serverless handlers while sleeping to free up billable compute resources”
A workflow can sleep or wait for days to months without holding a server, connection, or billable computefullproof ↗
“Terminal errors end an invocation immediately and propagate the error to the caller instead of retrying”
Every step retries automatically with configurable backoff, timeouts, and failure policies — no try/catch scaffoldingfullproof ↗
“Testcontainers-based utility runs a real Restate Server in Docker to test handlers”
One command runs the whole engine locally, and testing utilities let me unit-test workflows with time skipping and mocked stepspartialproof ↗
“Ensures retries of an invocation always hit the same service version/endpoint for safe deploys”
I deploy new workflow code while in-flight runs finish on the version they started with — versioning without breaking determinismfullproof ↗
“Official plugin teaches coding agents Restate SDK APIs, patterns, and pitfalls for building apps”
First-party integrations wrap my AI stack — AI SDKs, agent frameworks, model providers — so agent steps get durability without glue codepartialproof ↗
Undersold (19)
Point an agent at llms.txt or agent-oriented docsfullproof ↗
Run the product headlessly / in CI for automationfullproof ↗
Set up automations that run autonomously in the backgroundfullproof ↗
Test against a sandbox environment without touching production datapartialproof ↗
Rely on versioned APIs with a documented deprecation policypartialproof ↗
Define rules that trigger actions automatically on eventspartialproof ↗
Failure rates, latencies, and queue depths export to my observability stack, and alerts fire when workflows misbehavepartialproof ↗
I replay or rerun a failed workflow from its recorded history — optionally from a specific step — to debug and recoverpartialproof ↗
Do everything through the API that I can do in the UIfullproof ↗
I assign priorities to runs and get fair scheduling across tenants instead of a single FIFO queuepartialproof ↗
Throughput scales by adding workers — the platform load-balances tasks across the fleet and tolerates worker losspartialproof ↗
Choose where my data is stored (region/residency)partialproof ↗
Events from my app, webhooks, or queues trigger workflows declaratively, and one event can fan out to many functionspartialproof ↗
I debounce, batch, or delay triggers so noisy event streams collapse into the runs I actually wantpartialproof ↗
I compose workflows from parallel steps, fan-out/fan-in over dynamic batches, and child workflows without hand-rolling coordinationpartialproof ↗
Claims outside our story set (3)
Real capability claims found in Restate’s own materials, but no story in this arena’s taxonomy covers them yet — that’s feedback on the taxonomy, not a mark against the product.
“Lets services maintain durable state shared across functions with strong consistency”
source ↗“Native request identity lets SDKs cryptographically verify requests came from a specific Restate instance”
source ↗“Provides distributed durable primitives (workflows, state, timers) usable across many use cases”
source ↗
Business model
Self-host free (BSL 1.1 source-available). Restate Cloud usage-based on durable actions: $25/M standard, $15/M at volume, storage $0.5/GB-mo, free tier; BYOC and multi-AZ add-ons custom-priced.
pricing ↗Score trend
How this product’s scores have moved as evidence and verdicts are re-derived — a point per change, not per day.
Try Experimental
Run it in the microterminal →Recorded agent sessions — and a live MCP handshake where the vendor ships one.
Flag
⚑ Flag a verdictThink a verdict is wrong? Opens a prefilled GitHub issue — or use the ⚑ next to any verdict above.
For agents
Agent surface uptime MCP up · llms.txt up (tracking since Sep 11 '26)