Why rflow?
rflow is a self-hosted workflow engine for durable EVM operations. Protocol and treasury teams can replace keeper scripts and orchestration glue with one YAML configuration, a persistent workflow journal and an embedded indexer and relayer. It supports your signing provider and RPC endpoints, with one Postgres database per independent project. Off-chain-only workflows also work without networks or signers.
How it compares
Comparison checked September 15, 2026, against the linked primary documentation. The table describes packaged capabilities and operating models. Programmable alternatives can add coordination and policies in application code.
| Product | Operating model | Workflow and operations capabilities |
|---|---|---|
| rflow | Self-hosted Rust binary + Postgres; operator-selected signing provider | YAML workflows with a durable journal, native approvals, cross-chain waits, reorg responses, trigger replay and MCP administration |
| OpenZeppelin Relayer + Monitor | Self-hosted services; managed option available | Monitoring and transaction relaying, configurable signing, scripts and TypeScript plugins for custom responses |
| Tenderly | Hosted platform; JS/TS Web3 Actions | Event, block, cron and webhook automation; historical simulations and forks; MCP tools for simulation, tracing and development |
| Gelato Functions | Network-operated execution; Solidity/TypeScript functions | Time/event/block triggers, APIs, secrets, storage and transaction batching |
| Chainlink CRE | Go/TypeScript workflows on decentralized oracle networks; production deployment requires access approval | On/off-chain orchestration, local simulation, consensus execution and workflow lifecycle tools |
| Goldsky Compose | TypeScript tasks with local development and cloud execution | Durable on/off-chain workflows, persisted state, execution tracing and sandboxed tasks |
rflow combines indexing, transaction management and durable workflow controls in infrastructure you operate. Simulation, automation and MCP are shared capabilities across the space; rflow's focus is making them part of the same operational workflow.
The differentiators
Durable recovery with defined boundaries. Deterministic trigger identities are
claimed once while their journal entries are retained, completed steps reuse their
stored results, and relayer transaction attempts use persisted idempotency keys.
Recovery reconciles an ambiguous send by its key. HTTP calls, notifications and
commands can repeat if a crash happens after the external effect but before its
outcome is stored; those receivers or commands need their own idempotency. Webhook
and stream deliveries need a stable idempotency_key to deduplicate within the
configured TTL. These guarantees do not imply chain finality or prevent an explicit
retry from creating a new attempt. Read the details.
Workflow controls in the journal. A simulated transaction can park behind a human approval gate, and a cross-chain wait can persist its event conditions and deadline across restarts. The same history shows what triggered the run, what each step decided and which transaction it queued.
Rehearse the workflow before enabling sends. Replay and test
rehearse historical event/block triggers or supplied fixtures in a separate session
journal. Reads and simulations use the configured RPC state; rflow does not
reconstruct historical external API responses. Use forks and fixtures where that
state matters. Dry-run suppresses built-in sends, HTTP calls and notifications,
but command: steps execute by default unless configured with dry_run: skip.
Reorg-aware where it matters. Confirmations are per-trigger, so the same event can
alert at head (confirmations: 0) and pay at depth. rflow validate prints per-chain
depth advice and warns when a head-fired trigger sends funds. See
Reorgs.
Transaction management is integrated. Nonce management, gas pricing, gas bumping, rebroadcast, stuck-tx replacement, per-relayer allowlists and automatic top-ups are rrelayer's job, embedded in-process. rflow never re-implements them: once a transaction is queued, rrelayer owns it.
One deployment you operate. The engines are internal; rflow exposes a single health/status port. You choose the host, database, RPC endpoints and signing provider, including raw keys, KMS or supported remote custody integrations.
Embedded engine hand-offs. The indexer, expression evaluator and relayer share one process, reducing service-to-service coordination. End-to-end latency still depends on RPC access, database work, polling and confirmation settings. Network head tracking uses polling; the separate WebSocket stream trigger is for external message feeds. rflow targets durable operations rather than latency-sensitive trading.