Flezha - a durable runtime for streams, workflows and agents

Hi all,

I’ve been working on Flezha for quite a while now, and I’ve finally decided to make it public. What it is and how to get started is on the website and in the docs, so here I’ll keep to the background and a few technical details.

Why I built it

Every time I needed a new kind of data processing, I ended up adding another product to the server. One for streams, one for workflows, something else for scheduled jobs. Each of them had its own deployment, its own monitoring and its own way of breaking, and most of my time went into keeping them all alive rather than into the actual logic.

At some point I noticed that underneath they all needed the same thing, a piece of code that holds some state and must not lose it when something crashes. So I wanted to see if one platform could cover all of these shapes with the same few building blocks, so there’s only one thing to run and look after.

A few technical details

The controller is an Elixir application. The running pieces (relays) are spread across the cluster with ProcessHub, and socket I/O on the controller side is done in a Rust NIF. Your own code runs in a separate runner process that connects to the controller over a Unix socket. There are SDKs for Elixir, Java, Rust, Python, Node, Ruby, PHP and Go.

All SDKs sit on one shared Rust core, and each language only has a thin binding on top of it (Rustler, JNI, N-API, PyO3, magnus, ext-ffi, cgo). One core keeps the system behaving as one. It’s capable enough for every language, more reliable, and the SDKs don’t slowly drift apart. The downside is that every SDK needs a native library. Prebuilt binaries ship for Linux (x86_64 and arm64) and macOS (Intel and Apple Silicon), and anywhere else you need a Rust toolchain to build it yourself.

How it was built

When I started the project years ago, I wrote all the code myself. Back then I didn’t really know where it would end up, I just built whatever I needed at the time. Over the last stretch almost all the code has been written with AI, and I’ve been more of an architect and tester.

I learned a lot from that, mostly by making mistakes. With AI the code grows much faster than you can read it, let alone keep the whole picture in your head and test it properly, and a few times I realised the project had grown over my head and I no longer really knew how parts of it worked. Each time I stopped adding features and did a big round of refactoring, renaming and rebuilding, until the structure made sense to me again. Staying on top of things turned out to be the real work, much more than getting code written. I might write a separate post about how this way of working went for me, what turned out to work well and what didn’t.

Where it stands

I’ve been using Flezha internally until now, and only recently felt confident enough to make it public. It’s still early. It works for what I use it for, but I’m sure there are bugs and rough edges I haven’t found yet, and interfaces may still change before 1.0.

Feedback and bug reports are very welcome, and so are opinions on the design. If something doesn’t make sense or breaks, I’d really like to hear about it.

Website: https://flezha.com
Docs: https://docs.flezha.com
Web console (Phoenix LiveView): GitHub - Flezha/flezha_console: The web console for operating a Flezha cluster · GitHub
Elixir SDK on Hex: flezha_sdk | Hex