Obelisk

Obelisk is an open-source durable and deterministic workflow engine written in Rust, built on the WASM Component Model. It is licensed under the GNU Affero General Public License v3.0 and is actively developed under the obeli-sk GitHub organization. The project is currently in pre-release, with the README warning that CLI, gRPC, WIT, and database schema are subject to change.

What It Is

Obelisk is a workflow engine that persists every step of a long-running function — every activity call, sleep, result, and log message — to an execution log backed by SQLite or Postgres. When a server crashes or restarts, workflows replay from the last completed step, guaranteeing no work is lost. The engine enforces a strict separation between deterministic workflow orchestration logic and side-effectful activities, making it suitable for building crash-resilient background jobs, periodic tasks, batch processing, and AI-assisted automation pipelines.

Architecture and Deployment Model

Obelisk ships as a single binary with no brokers, sidecars, or YAML pipeline layers. Key architectural choices include:

• WASM Component Model: Components are sandboxed, language-agnostic, and interoperable. Schema is defined in WIT IDL.
• Storage: Embedded SQLite for single-node deployments; Postgres for multi-node and high availability.
• Interfaces: Web UI on port 8080, Webhooks on port 9090, gRPC API on port 5005, and a CLI.
• Supported platforms: Linux x64/arm64 (musl, glibc v2.35+, NixOS) and macOS x64/arm64.
• Distribution: Components can be pushed and pulled from any OCI registry.

Core Workflow Capabilities

Obelisk provides a rich set of durable execution primitives:

• Crash recovery: The execution log records every step; workflows resume from the last completed step after a restart.
• Auto-retry: Activities are retried automatically on timeout, trap, or error, with configurable retry policies per component.
• Structured concurrency: Multiple child executions can be submitted in parallel and awaited individually or collectively; unawaited activities are automatically cancelled when the parent completes.
• Persistent sleep: obelisk.sleep() is durable and survives server restarts.
• Saga pattern: Nested workflows can guarantee cleanup via compensating activities even after a crash.
• Cron scheduling: Recurring tasks declared in deployment.toml using standard five-field cron expressions or named shorthands.

JavaScript and Exec Activities

Beyond WASM components written in Rust or other WASM-compatible languages, Obelisk supports plain JavaScript activities and workflows with no build step required — just .js files pointed to in deployment.toml. An "Exec activities" feature (introduced in 0.38) allows any executable — shell scripts, Python scripts, Docker commands — to be a durable activity with the same retry, timeout, and observability guarantees as WASM and JS components. Self-contained deployments can inline JS and shell scripts directly in deployment.toml.

Developer Experience and Observability

The Web UI provides a visual trace view with color-coded join sets, a step-through debugger, and execution filtering by FFQN or execution ID. Structured log output and forwarded stdout/stderr are stored in the database alongside execution events. Outgoing HTTP calls made by activities are captured in the execution log on failure and timeout events. The full HTTP API exposes an OpenAPI schema, and the CLI covers execution submission, component management, and deployment operations.

Update: v0.38.2

The latest release is v0.38.2, published on 2026-05-29. The 0.38 series introduced exec activities (shell scripts, Python, Docker as durable activities), self-contained deployments with inline JS and shell scripts in deployment.toml, step-through debugging via Web UI/CLI/REST API, and idiomatic JS imports using import instead of FFQN strings. The project has been actively releasing across a long version history (from v0.19 through v0.38) and the GitHub repository shows ongoing commits as of May 2026.