Obelisk

A fast Open-Source Durable & Deterministic Workflow Engine

Install Get Started
Install
curl -sSf https://raw.githubusercontent.com/obeli-sk/obelisk/main/download.sh | bash
obelisk generate prompt 'Create a workflow that fans out weather
    lookups for a list of cities in parallel' | claude

The agent writes JavaScript activities, workflows, webhook endpoints, and a deployment file.

cargo generate obeli-sk/obelisk-templates

Use Rust starter templates or any WASM Component Model-compatible language.

Run
obelisk server run --deployment deployment.toml

Use Web UI at :8080, Webhooks at :9090, API at :5005 or CLI to interact with the deployed application.

Execution list in the Web UI

Execution list — browse and filter all workflow and activity executions

Parallel workflow execution trace in the Web UI

Execution trace — parallel fan-out activities visualised in a timeline

Execution event log in the Web UI

Execution log — every workflow step persisted for deterministic replay

Logs in the Web UI

Logs — structured log output and stdout/stderr from executions

Advance modal in the Web UI

Step-through debugging — inspect the Advance modal before writing new execution log entries

Why Obelisk?

Crash-Resilient Workflows

Every call, sleep, and result is persisted to the execution log. Crash mid-workflow — it resumes from the last completed step on restart.

Simple Architecture

Single binary, embedded SQLite or Postgres. No brokers, no sidecars, no YAML pipelines.

Sanity for the Age of AI

Claw-like agents blur planning and side effects into an opaque, breach-prone tangle. Obelisk keeps them strictly separate: deterministic execution, contained secrets, full audit trail.

See all features →

Frequently Asked Questions

Why are deterministic workflow engines awesome?

Workflows are long-running, crash-resilient functions. The engine persists every step — so a workflow can pause for days or months, survive server restarts, and always resume exactly where it left off.

What is the difference between a workflow and an activity?

A workflow is pure orchestration logic — deterministic and side-effect-free. An activity does real work: HTTP calls, file I/O, database writes. Activities must be idempotent so the engine can retry them safely on failure.

What does determinism mean in the context of a workflow engine?

The engine records all non-deterministic calls — random values, timestamps, child results — to the execution log. On crash recovery, the workflow replays from the log, so the same inputs always produce the same execution path.

When does a code change break determinism?

Only when it changes the sequence of recorded events. Refactoring, adding log statements, or changing logic that runs after the last recorded event is safe.

What happens when the system crashes?

Workflows restart and replay completed steps from the execution log. In-progress activities are retried; finished ones return their recorded results — no work is lost.

How to handle cleanup after a permanent activity failure?

Invoke a compensating activity from the workflow to roll back side effects — the saga pattern. The workflow catches the failure and always runs cleanup before exiting.

What is the relation to AI?

AI-generated workflows are non-deterministic at authoring time — the same prompt can produce different logic on different runs. Obelisk enforces a strict separation between workflow design and execution: once deployed, every step is deterministic and recorded. When something goes wrong, the execution log — events, responses, child executions, logs, and source code, accessible via Web UI, REST, or CLI — answers exactly why it happened. This auditability and predictability stands in sharp contrast to today's agentic tools, where planning and side effects blur together.