DuraGraph
Self-hosted, event-sourced orchestration for durable, replayable AI agent workflows in a single binary.
- Source repo
- Duragraph/duragraph
- Stars
- ★ 161
- Last updated
- 1mo ago
- License
- Apache-2.0
- Primary language
- Go
- FA score
- 50/100 · Major gaps
At a glance
- How it runs
- Works with
- Portable with changes
- Cost
- Free, no paid service needed
- Setup effort
- Low · running in minutes
- You'll need
- Typical use
- Teams running long-lived LLM agents that can execute for hours and who need a worker to resume from the last committed state after a crash rather than losing the run.
- Not a fit if
- Teams needing multi-tenant isolation today
- Teams unwilling to learn event sourcing and CQRS
- Teams needing production Helm charts and workflow versioning
- Source review
- 50/100 · Major gaps
What does this agent do, and when should you use it?
DuraGraph is a self-hosted, enterprise-oriented orchestration layer for AI agent workflows built around one idea: every state transition is written as an immutable event to PostgreSQL in the same transaction as the work itself. That makes runs crash-safe and replayable — if a worker dies mid-tool-call, the engine resumes from the last committed state instead of losing work or re-executing it. The repository is a monorepo: cmd/duragraph holds the single control-plane binary (engine, embedded dashboard, dev bootstrapper), internal/ implements DDD, event sourcing and CQRS layers, dashboard/ is a React + TanStack Router + xyflow console with a visual workflow editor embedded into the binary at build time, python/ and go-sdk/ provide worker SDKs, examples/ ships Go and Python reference agents, and deploy/ carries Docker assets, SQL migrations and Helm charts. The external surface is a stable REST + SSE API over runs, threads, assistants and graphs, and workers register graph definitions on startup through the SDKs — no code generation or DSL. Deployment is two-mode: dev runs embedded PostgreSQL and NATS in the one binary, production points at external Postgres and NATS.
Workers connect to the control plane with the Python or Go SDK and register their graph definitions at startup. Clients create work with POST /api/v1/threads/:id/runs; the graph execution engine then walks nodes, edges, conditional branches, human-in-the-loop interrupts and tool calls, persisting each state transition as an event in the PostgreSQL event store as part of the same transaction. If a worker crashes, the engine resumes from the last committed state without double execution. An outbox relay forwards domain events to NATS JetStream, which drives SSE and dashboard updates decoupled from write throughput. Read paths go through CQRS queries: GET /api/v1/runs/:id fetches run state, GET /api/v1/threads/:id/runs lists a session's runs, GET /api/v1/threads/:id/runs/:run_id/stream streams live execution events, POST /api/v1/assistants registers an assistant and GET /api/v1/assistants/:id/graph introspects graph topology. OpenTelemetry-friendly Prometheus metrics are exposed as well.
- Teams running long-lived LLM agents that can execute for hours and who need a worker to resume from the last committed state after a crash rather than losing the run.
- Engineering groups that need auditability: every state change is timestamped, ordered and signed by aggregate version, so evals and compliance views can be built directly on the event store.
- Developers debugging a failing production run who want to step through the exact sequence of decisions that produced it instead of reading a stack trace and a vague last-known position.
- Individuals or small teams who want to try an agent workflow locally with zero infrastructure: one
duragraph devcommand starts the engine with embedded Postgres and NATS, then the Playground sends the first message. - Existing Go or Python agent codebases that can register graph definitions via go-sdk or the python/ SDK without adopting a new DSL or running a code generator.
- Platform teams standardizing on a self-hosted control plane with REST + SSE APIs, an embedded dashboard and Prometheus metrics, planning to swap in external Postgres and NATS for production.
How do you install or deploy this agent?
Four install paths are documented:
# Homebrew (macOS, Linux)
brew install Duragraph/tap/duragraph
# One-line install script
curl -fsSL https://duragraph.ai/install.sh | sh
# From Go
go install github.com/Duragraph/duragraph/cmd/duragraph@latest
# Or grab a prebuilt binary
# → https://github.com/Duragraph/duragraph/releasesFor source development:
git clone https://github.com/Duragraph/duragraph.git
cd duragraph
task dev # runs the engine + dashboard against a local Postgres + NATS
task test # unit + integration suiteCredentials: none are needed up front — dev mode embeds PostgreSQL and NATS, and the first sign-in uses the bootstrap admin printed in the startup logs. Production expects external PostgreSQL and NATS; deploy/ contains Docker and SQL migrations, while production Helm charts are still listed as in flight.
How do you use this agent?
Start the server:
duragraph dev
# → Engine + dashboard on http://localhost:8081Run your first agent: open http://localhost:8081, sign in with the bootstrap admin printed in the logs, go to Playground, pick a registered assistant and send a message. Each node lights up as it runs, the full graph topology is visible, and a replayable event log is available under Traces. The examples/ directory has RAG, tool-using agent, document processing and eval references in Go and Python that run against duragraph dev out of the box.
Connect your own agent: start a worker and register graph definitions through the python/ or go-sdk/ SDK, then drive runs over the REST + SSE API:
POST /api/v1/threads/:id/runs # create a run
GET /api/v1/runs/:id # fetch run state
GET /api/v1/threads/:id/runs # list a session's runs
GET /api/v1/threads/:id/runs/:run_id/stream # SSE: live execution events
POST /api/v1/assistants # register an assistant
GET /api/v1/assistants/:id/graph # introspect graph topologyWhat are this agent's strengths and limitations?
- Genuine event sourcing + CQRS + outbox implementation: every state transition is committed in the same PostgreSQL transaction as the work, so a crashed worker resumes from the last committed state with no double execution, and any run can be replayed from its event log for debugging or audit.
- Near-zero setup friction in dev: a single binary embeds PostgreSQL and NATS, so
duragraph devbrings up the engine and dashboard without docker compose or infrastructure provisioning. - Two first-class worker SDKs (Python package
duragraphon PyPI, plus go-sdk): workers register graph definitions on startup, and no code generation or custom DSL is required. - Broad operational surface: a stable REST + SSE API, an embedded React + xyflow dashboard with a visual workflow editor and Traces session view, OpenTelemetry-friendly Prometheus metrics, plus Docker assets and SQL migrations under deploy/.
- Apache-2.0 licensed, with the control plane, SDKs, dashboard and docs kept in one monorepo so they evolve against a single spec.
- Production readiness has documented gaps: multi-tenant and NATS Accounts isolation, production Helm charts, and workflow versioning and migrations are all listed as in flight.
- Observability is incomplete today: the per-node REST spans endpoint does not exist yet and execution events are SSE-only.
- Production deployment reintroduces infrastructure burden: dev embeds Postgres and NATS, but the README states production uses external PostgreSQL and NATS, so you take on operating both.
- The architecture requires buy-in: teams need to understand event sourcing, CQRS and the outbox relay pattern, which is real cognitive overhead if all you wanted was a linear agent script.
- No LLM provider or model adapter is documented, and no migration path is described for moving from other agent runtimes, so model-side fit cannot be judged from the available evidence.
How does this agent compare with similar options?
The README positions DuraGraph as "Temporal for AI agents" and states it uses the same architecture Temporal applies to general-purpose durable workflows, specialized for the shape of AI agent graphs (nodes, edges, conditional branches, human-in-the-loop interrupts, tool calls). It also contrasts with LangChain-class orchestrators, which store only the current state of a run and leave you with a stack trace and a vague last-known position when something breaks.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| DuraGraph This agent | 50 · Major gaps | CLIFree | ★ 161 | 1mo ago | Go | — |
| MUXI AI Application Server | 52 · Major gaps | CLIFree + model costs | ★ 178 | 1mo ago | — | — |
| Statewave Agent Memory Runtime | 72 · Some gaps | Self-hosted serviceFree + model costs | ★ 257 | 15d ago | Python | OpenAI API · Claude API |
| Maze: Distributed Framework for LLM Agents | 62 · Some gaps | CLIFree | ★ 608 | 19d ago | Python | — |
How does FollowAgents rate this agent?
Why each dimension lost points
The README describes major data paths including event storage, NATS relay, API, and workers; the worker source also lists connection configuration, capacity, and deregistration, giving some visibility into data flow (2). The supplied material does not adequately explain permission boundaries, sensitive-data retention or redaction, confirmation for external side effects, or rollback. The example secrets file warns against committing real credentials but does not show runtime credential protections. A private security-reporting channel is specified, but publisher identity and ownership are unverified, so attribution evidence is limited (1 for the remaining criteria).
The README and source describe event persistence and replay, while worker code covers heartbeat, drain, and deregistration. The worker returns specific errors for missing or malformed configuration, and the main program exits nonzero on command errors (failure_messages 2). However, the README Go-version badge conflicts with Go 1.25.0 in go.mod and Go 1.23 in the Act environment example. The supplied source does not substantiate the README's reliability guarantees in enough depth. The dependency list is specific, but availability and fallback behavior are not documented, so self-consistency and dependency availability score 1.
The README targets developers building and running workflows, names Go and Python SDKs, and lists RAG, tool use, document processing, and evaluation scenarios. It distinguishes embedded development data services from external production services (audience_and_scenarios and environment_fit 2). It also identifies missing multi-tenancy, per-node spans, production Helm charts, and workflow version migrations, which sets some capability boundaries (2). Trigger conditions, scope, and unsuitable cases are not systematically documented, so trigger_precision is 1.
The README organizes information with a directory table, architecture diagram, API examples, and contribution guidance. It gives concrete installation and startup steps and links examples and documentation (these criteria score 2). The complete Apache 2.0 license file agrees with the README declaration, earning 3. Naming is mostly stable, but the canonical and legacy entry points coexist, and the example environment's Go version conflicts with go.mod, so naming stability is 1. The README lists work in progress, but the supplied material has no versioned changelog or clear maintenance owner. A security email and contribution path exist, but publisher identity is unknown, so those criteria score 1.
The product offers a single-binary development setup, Python and Go SDKs, graph execution, and an observability interface; the README gives a usable first-run path and describes a clear workflow-orchestration benefit (output_usability and marginal_value 2). Embedding PostgreSQL and NATS reduces local setup, while production still requires external data services and multi-tenancy and production Helm support remain in progress. Cost and operational benefits are plausible but not quantified, so cost_benefit is 2.
The README's architecture diagram, endpoint examples, directory map, and installation commands make several claims traceable; worker source supports some configuration and lifecycle details (claim_traceability 2). The supplied material does not adequately corroborate core reliability, auditability, and enterprise-readiness claims, and the version information conflicts across README, Go module, and environment sample, so cross-source corroboration is 1. The materials do not consistently separate implemented facts from claims needing validation. The status section distinguishes completed and in-progress work, but major guarantees remain project assertions, so fact_inference_separation is 1.
- Do not treat the README's enterprise-readiness, recovery, or audit statements as source-verified production guarantees; the supplied material does not adequately show access controls, sensitive-data protections, or rollback.
- Check the actual Go build requirement: go.mod specifies 1.25.0, while the CI environment example specifies 1.23; the README badge value cannot be checked from the supplied material.
- The README lists multi-tenancy, production Helm charts, and workflow version migrations as in progress; confirm their implementation before relying on them in production.
Maintain this project? Add the FARS badge to your README
[](https://followagents.com/en/agents/duragraph)<a href="https://followagents.com/en/agents/duragraph"><img src="https://followagents.com/badge/duragraph.svg" alt="FARS review"></a>Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
Docker ```bash docker pull duragraph/duragraph:v0.8.1 ``` What's Changed * feat(cmd): wire the rebuilt control plane into the binary by @adwiteeymauriya in https://github.com/Duragraph/duragraph/pull/247 * docs(changelog): correct 0.8.0 and record 0.8.1 by @adwiteeymauriya in https://github.com/Duragraph/duragraph/pull/248 Full Changelog: https://github.com/Duragraph/duragraph/compare/v0.8.0...v0.8.1View on GitHub ↗ -
Release notes excerpt
> [!IMPORTANT] > Correction, added after release. The features listed below are real and are in the repository, but they were not reachable from the binary this release ships. > > The release pipeline builds ./cmd/duragraph, and that command imported none of the controlplane/ packages. If you installed v0.8.0 and ran duragraph serve, you got the previous implementation — in which llm.token, checkpoint.saved and the SSE heartbeat are absent, cron advances its schedule and logs "cron triggered" without creating any run, and completed runs record no output. > …View on GitHub ↗ -
Release notes excerpt
Docker ```bash docker pull duragraph/duragraph:v0.7.7 ``` What's Changed * fix(auth): dashboard auth gate honors /info instead of just localStorage by @adwiteeymauriya in https://github.com/Duragraph/duragraph/pull/208 Full Changelog: https://github.com/Duragraph/duragraph/compare/v0.7.6...v0.7.7View on GitHub ↗
FAQ
Does dev mode truly need no external infrastructure?
duragraph dev serves the engine and dashboard on http://localhost:8081 with nothing to provision and no docker compose; production deployments switch to external PostgreSQL and NATS.What happens when a worker crashes or a tool call fails?
How do I observe execution outside the dashboard?
Which LLM providers are supported?
Can it be used in a multi-tenant setup?
Thanks — we use this to improve the page.