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.
The operator owns secrets and the outbound HTTP allowlist in server.toml. Runtime
access is the intersection of operator policy and each deployment's, so a deployment can only
narrow it. Secrets are injected at the network edge and never reach the sandbox, its logs, or the
database, which is what makes agent-authored deployments safe.
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.
obelisk deployment verify compiles and checks a deployment with no running server or
database. --fix repairs content digests, updates the exec allowlist, and scaffolds
missing secret declarations, the loop an author runs before submitting.
The submitted deployment.toml and its owned source files are the stored source of
truth. Reconstruct any past deployment back to disk with deployment get, even after
the active one has moved on.
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.
The API port denies unauthenticated requests by default and accepts bearer tokens over REST,
gRPC, and gRPC-web. Token hashes live in server.toml, so the config stays safe to
commit. Webhook endpoints stay open.
Exec activities run host processes outside the WASM sandbox, so they are disabled by default and
opt in globally or by allowlisting reviewed script digests in server.toml.
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.