Skip to content
orch8.io

Orch8 · durable workflow engine

Keep AI agents running after the request ends.

Orch8 checkpoints long-running workflows across crashes, deploys, human approvals, and lost connectivity. The same Rust runtime runs on servers and offline-capable mobile devices.

Built for work where repeating a completed step is dangerous. For a short stateless job, use a queue.

Crash a workflow liveRun the two-minute quickstart

Watch orch8 demo crash-recovery reclaim a crashed run →

Temporal-class durability in one self-hosted binary, with an embedded path for iOS and Android.

execution_01J8

One identity across every placement

running
  1. 1CloudAgent calls a toolcommitted
  2. 2HandoffWork moves to a deviceclaimed
  3. 3iPhoneLocal steps run offlinelocal
  4. 4HumanApproval pauses safelywaiting
  5. 5CloudThe same run continuesresumed

Completed boundaries stay completed. Only the next eligible step runs.

Pick your starting point

Three ways teams start with Orch8.

Start with the smallest problem you have today. Every path runs on the same engine, so a cron job can grow into a durable workflow without switching tools.

Background jobs & cron

Enqueue a job with a single HTTP call, or put it on a cron schedule. Retries and the dead-letter queue come from the same durable engine, so you don’t need to write a workflow first.

enqueue a job
curl -X POST http://localhost:8080/api/v1/jobs \
  -H "content-type: application/json" \
  -H "x-tenant-id: acme" \
  -d '{ "handler": "send_invoice_reminders",
        "payload": { "account_id": "acct_42" },
        "retry": { "max_attempts": 5, "initial_backoff_ms": 1000 } }'

Beta API. Retries, delays and idempotency keys are optional fields.

Read the jobs docs →

Durable AI agents

Run a think–act loop where every LLM and tool call is a checkpointed step. A crash or deploy resumes the loop without repeating completed tool calls.

agent_loop.json
{
  "type": "loop",
  "id": "agent_loop",
  "condition": "context.data.done != true",
  "max_iterations": 10,
  "body": [
    { "type": "step", "id": "think", "handler": "llm_call",
      "params": { "provider": "openai", "model": "gpt-5.6-luna" } },
    { "type": "step", "id": "act", "handler": "tool_call", "params": {} }
  ]
}

Always cap agent loops with max_iterations.

Build a durable agent →

Offline mobile workflows

Embed the same Rust engine in an iOS or Android app. Workflows run from local SQLite with no connection, then sync status when the device is back online.

Onboarding.swift
let instanceId = try engine.start(
    sequenceName: "onboarding_v2",
    input: "{\"user_id\": \"abc123\"}",
    dedupKey: "onboarding:abc123"
)

Native iOS and Android through UniFFI.

Read the mobile SDK guide →

Proof you can inspect

Do not take a runtime’s recovery claims on faith.

There are no invented customer quotes or unlabeled benchmark tiles here. Test the failure path, read the code, and check the release history yourself.

Read the implementation

Inspect the Rust engine, storage adapters, migrations, and test suites.

Browse the source →

Review the trust boundary

See credential handling, encryption scope, disclosure, and deployment responsibilities.

Read security details →

How it works

Define a sequence. Commit each boundary. Resume the same run.

A sequence is a versioned workflow definition: steps, delays, branches, retries, signals, and placement rules. Orch8 owns the durable execution state; your handlers own the business logic.

Study the execution model →
welcome.json
{
  "id": "welcome_drip",
  "blocks": [
    { "type": "step", "handler": "send_email" },
    { "type": "step", "handler": "noop",
      "delay": { "duration": 259200000 } },
    { "type": "step", "handler": "human_review" }
  ]
}
curl -fsSL https://orch8.io/start.sh | sh
Review the install script sourceUse Docker or Homebrew instead

The runtime boundary

Use Orch8 when time, failure, people, or placement changes the workflow.

It fits agent tool calls, payment recovery, lifecycle automation, field operations, and any process that must remember exactly what has already happened.

Resume after failure

Checkpoints persist completed boundaries. A restart continues eligible work instead of replaying the whole workflow.

Protect side effects

Effect receipts and stable idempotency keys make payment, email, and API recovery decisions explicit.

Wait without holding compute

Delays, signals, approvals, and retries persist for seconds or days while workers remain free.

Run where the work is

Use the Rust server runtime or embed the same engine through UniFFI on iOS and Android with local SQLite state.

Compare with Temporal, Inngest, Trigger.dev, Hatchet, Airflow →Read the full documentation →Ask a technical question in Discord →

Talk to a human

Bring the workflow you are afraid to restart.

Tell us where it runs, which effects cannot repeat, and how long it may wait. We will reply with a concrete deployment path—or tell you a queue is enough.

Email the maintainerReview security first