OmniFlow runs the work that is too important for a cron job and too fiddly for a spreadsheet. Described in a short manifest, checked before it runs, executed from a single container, and recorded so you can explain every step.
Part of the NEXORA platform. Sign-in and billing through NEXORA arrive with the beta.
Illustration of a OmniFlow run: three steps, one waiting for approval, with a plain-language explanation beside it.
Run · approval-gated-refund 1.0.0
approval-gated-refundWaiting for approval
✓validate12 ms
IIsign-offpaused · free while waiting
3refundeffectful · idempotency key set
Explain this run
The run stopped at sign-off. Nothing after it has run.
It needs a different person from the one who started it.
If nobody answers in 4 hours, the refund is denied.
If you retry later, the refund still happens at most once.
Illustration. Real run pages show exactly this: what happened, what is true now, and what to do next.
1 containerNo cluster, queue or database to run first.
1 SQLite fileBackup and restore are one command each.
Exactly-onceEffectful steps carry an idempotency key.
Hash-chainedAn audit log that cannot be edited quietly.
Why OmniFlow
Built for the moment a step fails.
Most workflow tools are good at the happy path. OmniFlow is designed around what happens next.
Safe by construction
One effect, once.
Retries and crashes do not repeat a charge, an email or a deploy. The key is recorded before the step acts, so "did that go through twice?" has an answer.
Honest failures
Know why it stopped.
Failures are classified. Only the ones you choose are retried; the rest stop, roll back in reverse order, and say why in plain words.
Small to operate
Nothing to babysit.
One container and one file. It does not scale across machines, and we say so up front. If you need a cluster, this is not the right tool yet.
How it works
Describe it. Check it. See what happened.
Write or describe a workflow
A short manifest, or a plain-language draft that a person must review. AI may propose; it never runs anything on its own.
It is checked, then it runs
Unknown steps, bad references and missing idempotency keys are errors with a line number, found before anything runs.
Every run explains itself
Attempts, retries and approvals land in a tamper-evident log. Any run can be read back in plain text.
approval-gated-refund.yaml
# a person must approve before the refundsteps:
- id: validate
type: capability
uses: util-assert@^1
- id: sign-off
type: approval
dependsOn: [validate]
approvers: { roles: [approver, admin] }
timeout: 4h
onTimeout: deny
- id: refund
type: capability
dependsOn: [sign-off]
idempotencyKey: "refund-${{ inputs.orderId }}"
✓ valid · 3 steps · risk low · plan sha256:9f3c…
Capabilities
Everything a durable workflow needs. Nothing it doesn't.
Exactly-once effects
Idempotency keys are recorded before a step acts, so retries and restarts never repeat an effect.
Retry only what should be retried
Choose which failure classes retry. Contract and authorisation failures stop and explain.
Undo in order
Failed workflows roll back completed steps in reverse, with the rollback itself recorded.
Approvals that cost nothing while they wait
Four-eyes review for changes and for individual steps. A paused run holds no resources.
An audit trail nobody can quietly edit
Hash-chained events with a one-click integrity check and export.
One container
One SQLite file. Dry runs, canary versions and a kill switch are built in.
Not built yet, said plainly: retention and archival of old runs, and sign-in and billing through NEXORA outside development. Read the full picture.
Security & governance
Authority is earned, not assumed.
Default-deny network. Steps reach only the hosts they declare.
Secrets stay secret. Leased per step, scrubbed from logs, never stored in plans.
Four-eyes by default. Whoever requests a change cannot approve it.
OmniFlow