What is Ironflow?
A 60-second pitch: what Ironflow is, who it’s for, and when to reach for it.
Ironflow is a durable runtime for AI agents and event-driven systems. Building one normally means wiring an orchestrator, a broker, and an event store together and then owning the seams between them. Ironflow is those three in one binary: work resumes after a crash, waits for external input without holding a worker, and leaves behind a history you can inspect and replay.
The usual way
Three dependencies. The seams are yours.
With Ironflow
One dependency. No seams to own.
When to use Ironflow
Section titled “When to use Ironflow”- You have an agent that works for minutes across model and tool calls, and a crash today means paying for all of it again.
- You have a workflow that waits — on a human approval, a webhook, a supplier — for hours or days.
- You want events and execution steps in one history, so a bad run can be replayed instead of reconstructed from logs.
- You want read models derived from event history, and rebuilt when the shape of the view changes.
- You want all of that running locally as one process before you commit to it.
Who it’s for
Section titled “Who it’s for”Two kinds of engineer arrive here with the same problem.
- You have built event-driven systems before. You know what a broker and an event store cost to run, and you are not spending another quarter gluing them to a workflow engine.
- You have built agents. You hit durability the hard way — a long run died, a tool ran twice, and there was nothing to replay.
Both paths use the same primitives. Ironflow assumes you are comfortable running a binary, reading a stack trace, and owning your own data.
What Ironflow is not
Section titled “What Ironflow is not”- Not a model, and not an agent framework you have to adopt. You bring your own provider and your own prompts. Native agent APIs ship for Node, Go and Python, and a LangGraph checkpoint saver is there if you already use LangGraph.
- Not hosted-only. The default is self-hosted: one binary on your machine, your database, no account and no phone-home. Ironflow Cloud — a dedicated cluster, behind a waitlist — is planned for after 1.0, for when you would rather not run it yourself.
- Not a no-code builder. Workflows are TypeScript, Go or Python in your repository, reviewed and deployed like the rest of your code. The dashboard inspects; it does not author.
- Not an automatic recorder of everything. Entity streams keep event history by design. Step-by-step execution recording is opt-in — you turn it on for the functions you actually want to replay.
One continuous history
Section titled “One continuous history”Events and recorded execution steps land in the same append-only history. That
is what the rest of the product is built on: ask what happened, replay it, and
rebuild derived state from it, without a second system to reconcile against.
Entity stream events are kept until you delete the stream. Execution steps join
this history only for functions registered with recording on (recording: true
in Node, Recording: true in Go, recording=True in Python).
What’s in the binary
Section titled “What’s in the binary”
ironflow serve starts all five layers as one process — or run Ironflow
Desktop and skip the terminal. Multi-node deployments swap
SQLite for Postgres and the embedded broker for external NATS; nothing above the
foundation changes. The architecture goes layer by layer.
Start with Installation, then take the tutorial that matches your workload: build an agent that survives a crash, or emit, react, and derive in five minutes. Weighing this against something else? Read the platform comparison.