Obelisk 0.41 draws a firm line between what an operator controls and what a deployment can do. That line is what makes it safe to let an agent author, submit, and activate deployments: the operator sets secrets and outbound HTTP policy once in server.toml , and no deployment can exceed it, no matter who wrote it. Our proof of concept workflow-agent , where the workflow is the agent editing and…
Obelisk, Temporal and Restate all let a function keep making progress after its process disappears. The largest architectural difference is that Obelisk is a workflow runtime: it loads and runs application components itself. Temporal and Restate are orchestrators whose application code runs in separately deployed Workers or service endpoints. That difference shapes which mistakes each system can…
Obelisk 0.40 tightens two defaults that used to be wide open and improves how workflows see failed children. The API port now rejects requests without a token, host exec activities have to be enabled before they will run, and an awaited child failure now tells you whether it was a business error or a platform failure such as a timeout or cancellation.
Obelisk 0.39 makes deployments easier to inspect, reproduce, and move between environments. The server now stores the submitted deployment.toml together with deployment-owned source files, can reconstruct a deployment back to disk, and verifies deployment packages before they are persisted.
Obelisk 0.38 adds native executable activities, step-through execution debugging with the replay/advance API, and self-contained deployments where JS and shell scripts live directly inside deployment.toml .
DBOS recently argued that Postgres is all you need for durable execution : if you already trust your database, you do not need a separate orchestration tier. I agree with the direction, and I think the idea can be pushed further. For a large class of durable systems, SQLite is all you need.
Obelisk 0.37 ships first-class JavaScript support for all three component types — activities, workflows, and webhook endpoints — running inside a fine-grained permission sandbox. It also introduces the Deployment concept with hot redeploy, and built-in cron scheduling.
Obelisk 0.35 introduces workflow replay for debugging and version migration, execution pausing, persistent log storage, and streamlined component management with GitHub release support.
Obelisk 0.32 introduces cooperative cancellation for workflows and activities, a new WebAPI with multi-format support, and PostgreSQL support for multi-node deployments and high availability.
One of the big strengths of Rust is its use of automatic memory management. When a value gets out of scope, the compiler automatically calls its destructor and frees the memory. During my work on graceful shutdown I have stumbled on a less known interaction between scopes and the _ wildcard pattern that can lead to surprising order of destructors.
Obelisk and DBOS are both open-source durable workflow engines. Let's see how they compare in terms of ease of use, nondeterminism prevention and performance. I will go through the Learn DBOS Java tutorial and compare it with Rust version of the same code written for Obelisk. I chose Java because of familiarity, however the library has just been released so the code is still quite young. On…
November marks 2 years since I started working on Obelisk, an OSS workflow engine written in Rust. As a reflection on its capabilities I have decided to make a friendly comparison with WindMill , which produced an interesting benchmark accompanied by a blog post titled Fastest self-hostable open-source workflow engine .
Contrary to vibe coding, usually defined as irresponsible running of LLM generated code with no real code review, leading to security, debugging and maintenance nightmares, "vibe engineering" was defined as "iterating with coding agents to produce production-quality code". Here is how deterministic workflow engines, and specifically Obelisk, can help with the transition.
Obelisk is an open-source deterministic workflow engine that runs, stores, and replays WASM-based workflows using SQLite. The headline change in v0.25 : every function in workflows and activities is now required to be fallible. Obelisk maps execution-failed errors into the called function's return type. This ensures traps and errors are handled explicitly instead of silently breaking…
Obelisk is an open-source deterministic workflow engine that runs, stores, and replays WASM-based workflows using SQLite. There have been many changes since the initial public release 0.19.1 , mostly focused on structured concurrency ergonomics, adding more abilities to activities and exploring using other languages than Rust for authoring WASM Components.
This month has already seen five Obelisk releases, each focused on adding experimental JavaScript and Go support to the runtime. Although WASM format is source-language agnostic, both JavaScript and Go needed tweaks, workarounds and sometimes upstream tooling fixes to get fully working with the WASM Component Model . In this post we'll explore rewriting an activity, workflow and a webhook…
I'm excited to introduce Obelisk, a new workflow engine I've been passionately building for over a year. You can find the project hosted at obeli.sk and the source code openly available at github.com/obeli-sk/obelisk under an Open Source license. Recently, I shared Obelisk on Hacker News ( link to story ), and the response was very encouraging! It received over 100 upvotes, and…