MantisBase is Moving to Rust

There is no shortage of "rewrite it in Rust" stories on the internet. Some are driven by hype, others by genuine engineering needs. This is not the former. What follows is a straightforward account of where MantisBase is headed, why, and what it means for you.

A Growing Ecosystem Worth Taking Seriously

Before getting into the decision itself, it is worth acknowledging the state of Rust as a language and ecosystem. The Rustacean community has grown into one of the most active and technically rigorous developer communities in open source. The crates.io registry now hosts hundreds of thousands of packages, covering everything from async runtimes and HTTP frameworks to database drivers, JWT handling, and mailer integrations — all with first-class tooling and consistently high quality. Rust has also topped Stack Overflow's "most admired language" survey for several consecutive years, which speaks less to popularity and more to developer satisfaction once they have committed to it.

We have been watching this ecosystem closely. It has matured to a point where building a production-grade, single-binary backend on top of it is not only feasible — it is arguably the most sensible path forward for a project with MantisBase's goals.

What Is Already Happening

Work on v0.4 has begun, and it is a full rewrite in Rust. The goal is to reach feature parity with the current C++ release at minimum, and to go further where the new foundation makes it practical to do so. If you want to track progress, the master branch on GitHub already reflects the active rewrite — the repository is already building and running in Rust, with core functionality like entity schemas, REST routing, access rules, JWT authentication, admin dashboard serving, and webhook support already in place.

This is not a distant roadmap item. It is ongoing work, and it is further along than most announcements of this kind tend to let on.

Why the C++ Foundation Was Holding Us Back

MantisBase started as a C++ project for good reasons: raw speed, embeddability, and a single-binary deployment model with no external runtime dependency. Those goals have not changed. What changed is our assessment of the cost of continuing to pursue them in C++.

The C++ codebase accumulated a set of challenges over time — not insurmountable, but expensive to address correctly. Memory management patterns that required careful audit, integration complexity when pulling in third-party libraries, and a build system that made certain kinds of cross-platform testing harder than it needed to be. Fixing these properly would have demanded a significant investment of time — time that should have gone toward improving the product.

The practical result was that several things we wanted to deliver kept getting pushed back. The documentation site needed modernisation. The admin dashboard needed a cleaner, more capable UI. The REST API had features we wanted to expand. Most notably, out-of-the-box SDK support for JavaScript and Python — something users have asked about consistently — was hard to prioritise while we were managing the overhead of the C++ foundation.

We reached a point where the honest assessment was: the language itself had become a constraint on the project's growth, not just a technical detail.

Why Rust, and Not Zig or Go

Once the decision to move away from C++ was made, we evaluated the realistic alternatives that could preserve what made MantisBase useful in the first place: a single compiled binary, genuine performance, and low memory overhead. Rust, Zig, and Go were the serious contenders.

Go produces clean binaries and has an excellent standard library, but its garbage collector introduces latency characteristics that are a poor fit for a backend meant to be embedded inside other applications. Zig is technically compelling and offers tight control over memory, but its ecosystem and tooling are still maturing — pulling in third-party integrations would mean building more from scratch than we wanted.

Rust offered the right combination: compile-time memory safety without a garbage collector, a mature ecosystem through crates.io, and tooling (cargo, rustfmt, clippy, cargo test) that genuinely reduces friction rather than adding to it. The memory safety story was particularly relevant. Part of why the C++ codebase was difficult to maintain was precisely the category of issues that Rust eliminates at the compiler level — use-after-free, data races, invalid pointer dereferences. We could have audited and hardened the C++ code, but choosing Rust means we do not have to keep having that conversation on every future contribution.

Beyond safety, the crate ecosystem makes it straightforward to integrate capabilities that previously required significant custom work: mailer support via lettre, async HTTP with axum, database access via sqlx, and more. These are not afterthoughts — they are well-maintained, widely used libraries that slot in cleanly.

First-class test support via cargo test is also worth naming directly. Writing and running tests in C++ projects of this kind involves considerably more ceremony. In Rust, testing is a natural part of the workflow, which matters when you are trying to build confidence in a rewrite incrementally.

Language SDK Support Becomes Realistic

One of the things we wanted to offer from early on was MantisBase SDKs for JavaScript and Python — not just REST clients, but deeper integration. In the C++ world, producing idiomatic bindings for both languages meant navigating complex FFI boundaries, separate build pipelines, and significant maintenance surface.

From Rust, this is substantially more tractable. The PyO3 project provides a mature path for exposing Rust libraries to Python, and Neon (or WASM targets) covers the Node.js side. We are not committing to a specific release timeline for these yet, but the rewrite removes the structural obstacle that made them impractical before.

What Happens to C++ Support

The original C++ releases are not being abandoned. Binaries up through v0.3.5 remain available on the GitHub releases page, and that code is not going anywhere.

Looking further ahead, we are interested in the model that projects like Slint have demonstrated. Slint is a UI toolkit written in Rust that exposes a fully supported C++ API — developers working in C++ interact with it as though it were a native C++ library, with no Rust toolchain required on their end. Several other projects in the embedded and systems space have taken similar approaches. We are examining what that looks like for MantisBase's embedding use case, and C++ API support remains part of the long-term plan.

What to Expect Next

The v0.4 work is progressing in the open. You can follow along, open issues, or contribute via the GitHub repository. The current Rust codebase is already functional enough to run and experiment with.

A more detailed devlog covering the architecture of the Rust port — including database abstraction, the new schema engine, and the HTTP layer — is coming soon. For updates, subscribe below or follow @allankoechke on X.

MantisBase is an open-source, single-binary Backend-as-a-Service. Visit mantisbase.com for documentation and demos.