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
- 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
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
- 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 and Go, 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, in private beta behind a waitlist — is there when you would rather not.
- Not a no-code builder. Workflows are TypeScript or Go 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
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.
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.