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 execution.
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 from Rust. All code examples are available in the Stargazers repository.