The execution log records every activity call, sleep, result, structured log message, and outgoing HTTP trace. Server crash or restart? Workflows resume from the last completed step with full history intact.
Activities are retried automatically on timeout, trap, or error. Activities can also signal
permanent failure to skip remaining retries. Configure per-component retry policy and lock
expiry in deployment.toml.
Submit multiple child executions in parallel and await them individually or all at once. Unawaited activities and delays are automatically cancelled when the parent completes.
obelisk.sleep() is durable: its position is saved to the execution log. Survive a
server restart mid-sleep with no progress lost.
Nest workflows to guarantee cleanup runs even after a crash: the outer workflow catches inner failures and always executes compensation logic.
Declare recurring tasks in deployment.toml. Standard five-field expressions, named
shorthands (@daily, @hourly), or @once for one-time
migrations.
Pause any execution, then step through it one event at a time. Replay previews the next writes; Advance applies them. Verify a new component version produces identical results before deploying to production.
Stack traces attached to every execution log event: submits, joins, sleeps. Step through any execution in the Web UI and see the exact source line.
Plain .js files. No bundler, no compiler, no toolchain. Point
deployment.toml at the file and run.
Activities, Workflows, and Webhook endpoints, all in JavaScript. Import activities and workflows directly instead of calling by FFQN string.
Any executable (shell script, Python, Docker command) can be a durable activity with the same retry, timeout, and observability guarantees as WASM and JS components. Parameters arrive as JSON arguments, results go to stdout.
Math.random() and Date.now() are safe in workflow code. Values are
recorded on first call and replayed identically on crash recovery.
Outbound HTTP restricted to explicitly listed hosts and methods. Environment variables only expose declared keys. Token-based secrets injected without appearing in code, logs or database.
Every obelisk deployment apply stores a versioned snapshot of your full config.
Executions carry a reference to the deployment that ran them.
Update components without restarting the server. Activity workers pick up the new version immediately; in-flight workflows continue on the old digest until explicitly upgraded.
Inline JavaScript and shell scripts directly in deployment.toml with
content. A complete application (activities, workflows, webhooks) can live in a
single file. Local file paths are embedded at deploy time automatically.
Push and pull JS or WASM components from any OCI registry. Config (allowed hosts, env vars,
secrets, WIT types) is embedded in the manifest so component add restores
everything automatically.
Visual trace view with color-coded join sets and rail lines. Step-through debugger. Autoload child executions. Filter by FFQN or execution ID. Pause/resume controls.
Structured log output (five levels) and forwarded stdout/stderr stored in the database alongside execution events. Query logs for any execution via the CLI, API or Web UI
Outgoing HTTP calls made by activities are captured in the execution log on failure and timeout events. Inspect request URLs, status codes, and response details for any failed attempt via the API or Web UI.
Fetch execution events (with stack traces attached), follow responses and child executions, collect errors, stream logs, and retrieve source code, all via the API or CLI. AI agents can diagnose defects autonomously and push fixes via hot redeploy, no server restart needed.
Full HTTP API with OpenAPI schema. Submit executions, inspect state, fetch logs, replay, pause,
cancel, all scriptable with plain curl.
obelisk execution submit/list/logs, obelisk component add/push/inspect,
obelisk deployment apply/list. Everything from the terminal.
Built on the WASM Component Model. Components are interoperable, sandboxed, and language-agnostic. Schema defined in WIT IDL.
One process. No brokers, no sidecars, no orchestration layer. Embedded SQLite for single-node; Postgres for multi-node and high availability.
Source at github.com/obeli-sk/obelisk, written in Rust.