One of MantisBase’s biggest goals has always been embeddability in any C++ codebase. In the past, you had to compile MantisBase from source, and if you’ve tried, you know it can be daunting.

Our biggest v0.4.x goal was shipping a dev package with shared libraries and header files, so you don’t have to build from source if dynamic linking works for you.

This is part one of a two-part series: this post walks you through how to acquire and set up a MantisBase dev package. Part two will cover actually integrating it into your application.

Which version

From v0.4.0, we shipped a dev package, mantisbase_v0.4.0-dev.zip, with both static and shared libs plus header files. Unfortunately, the symbols weren’t exported correctly, which made most of it unusable.

That’s fixed as of the beta release v0.4.5, and we’ve also split the dev package by platform: mantisbase_v0.4.5-[linux/windows]-cpp-dev.zip. See the release page.

From this release onward, all necessary symbols are exported correctly. We no longer ship static libs for now; if you have a specific need for a static build, let us know!

Getting the dev package

Download the dev package for your platform (Linux or Windows) from the GitHub Releases page and unzip it to your desired directory.

Note: Header files for Windows and Linux are platform-specific, so they may not be 100% cross-usable.

The unzipped directory structure looks like this:

README.md        quick readme file
VERSION          release tag
include/         header tree for this OS (mantisbase headers + bundled
                 third-party headers: drogon, trantor, nlohmann/json,
                 jsoncpp, soci, spdlog, fmt, dukglue, duktape, wolfssl, ...)
libs/
  x86/           prebuilt shared library for x86-64 (libmantisbase.so) — Linux only
  arm/           prebuilt shared library for aarch64 (libmantisbase.so) — Linux only
                 (Windows ships x86_64 only, under libs/x86/)
cmake/
  MantisBaseConfig.cmake         find_package(MantisBase) entry point
  MantisBaseConfigVersion.cmake  version matching

On Linux, there are additional system prerequisites required at build and run time. Install them with:

sudo apt-get update
sudo apt-get install -y libpq-dev uuid-dev

Runtime shared libraries on Debian/Ubuntu are libpq5 and libuuid1.

Windows requires no additional system dependencies to build or run against the dev package.

Quick CMake integration

This example assumes Linux; the workflow is similar for Windows with the Windows dev package.

First, create an empty CMake-based project (via an IDE or any means you prefer). Copy the unzipped dev package into the project, e.g., into mantisbase-linux-cpp-dev/. The resulting directory structure looks like this:

CMakeLists.txt                  application CMake file
main.cpp                        application entry point
mantisbase-linux-cpp-dev/       same folder structure as before
    README.md
    VERSION
    include/
    libs/
        x86/
        arm/
    cmake/
        MantisBaseConfig.cmake
        MantisBaseConfigVersion.cmake

Point CMake at the package with find_package:

cmake_minimum_required(VERSION 3.22)
project(my_app)

set(MantisBase_DIR "/path/to/mantisbase-linux-cpp-dev/cmake")
find_package(MantisBase REQUIRED)

add_executable(my_app main.cpp)
target_link_libraries(my_app PRIVATE mantisbase::shared)

main.cpp:

#include <mantisbase/mantisbase.h>

int main(int argc, char* argv[])
{
    auto app = mb::MantisBase::create(argc, argv);
    return app->run();
}

Help

• Download dev package

• Documentation

• Discord

• GitHub Discussions

• Issues

Coming up in part two: actually wiring MantisBase into your application: configuration, plugins, and extension points.

This blog covers what Muse Code actually is, what it costs, and how to wire its Contributor-tier model into a stock Claude Code install.

What is Muse Code?

Muse Code is Meta’s terminal-based coding agent: a TUI for interactive development plus a headless exec mode for CI, built around Meta’s own code-focused model family, Muse Spark. It reads a codebase, plans and executes multi-file changes, runs commands, and iterates on failures, the same shape as Claude Code and Codex CLI. It launched with persistent background subagents and a replay-exact event log for crash recovery, and Meta has since added inter-session messaging and a TypeScript SDK for building custom agents on top of it.

On raw benchmark quality, most third-party comparisons place Muse Code below Claude Code but ahead of Codex CLI. Meta isn’t claiming the smartest model; it’s claiming the cheapest capable one.

Model types

The model family is Muse Spark, currently on version 1.3, and it ships in two pricing tiers that are otherwise the same underlying model:

• Standard: full data privacy; Meta does not use your prompts or completions for training, so they claim.

• Contributor: a steep discount in exchange for letting Meta use your prompts and completions to improve its products.

You select the tier by model ID (muse-spark-1.3 vs muse-spark-1.3-contributor), making it trivially easy for a quick setup and swapping models when needed.

Costs

Pricing is a straight pass-through of token costs, no separate license fee:

That’s roughly a 12x discount on input and a 21x discount on output. The catch, beyond the training-data trade, is throughput: Contributor is rate-limited well below Standard, so a team running heavy concurrent agent sessions may hit throttling on Contributor before they hit it on Standard. If you’re budgeting, model cost per accepted task rather than cost per token; Muse Spark has been reported to burn more tokens per task than Claude Code on equivalent work, which eats into the headline discount.

Why the Contributor model, and when it isn’t the right call

Contributor is the tier worth using day-to-day: for personal projects, open-source work, learning, or anything you’re not contractually obligated to keep private, a ~20x cost cut is hard to argue with, and Muse Spark at Contributor pricing is cheap enough to leave running in the background on exploratory tasks you’d never justify spending Opus-tier tokens on.

Where it stops being the right call is exactly where “Meta trains on this” becomes a problem: client code under NDA, anything with proprietary business logic, credentials or secrets in context, or a repository your employer would object to leaving the building. The switch is one config string, so if this matters to your team, it’s worth pinning the model ID centrally and treating any change to it as a reviewable event rather than something anyone can flip locally.

Setting up Muse Code inside your existing Claude Code CLI

Rather than installing a second CLI, you can route your regular claude command at Meta’s endpoint using the same environment-variable mechanism. Claude Code uses for enterprise gateways, Bedrock, and Vertex:

export MODEL_API_KEY="<your-meta-model-api-key>"
export ANTHROPIC_BASE_URL="https://api.meta.ai"
export ANTHROPIC_AUTH_TOKEN="$MODEL_API_KEY"
export ANTHROPIC_MODEL="muse-spark-1.3-contributor"
export ANTHROPIC_DEFAULT_OPUS_MODEL="muse-spark-1.3-contributor"
export ANTHROPIC_DEFAULT_SONNET_MODEL="muse-spark-1.3-contributor"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="muse-spark-1.3-contributor"
export CLAUDE_CODE_SUBAGENT_MODEL="muse-spark-1.3-contributor"

Get MODEL_API_KEY from your Meta Model API account, not from the muse CLI’s own OAuth login; the two auth paths are separate. Once these are exported, claude in any project directory, it talks to Muse Spark instead of Anthropic’s models while keeping every bit of Claude Code’s interface, skills, slash commands, and MCP tooling.

The four ANTHROPIC_DEFAULT_*_MODEL variables matter because Claude Code internally maps its own “which model handles this” logic (plan mode vs. execution, subagents, background tasks) to the Opus/Sonnet/Haiku tiers. Pointing all three at the same Muse Spark ID keeps that routing from silently falling back to an Anthropic model you don’t have credentials for.

The context window gotcha and the [1m] workaround

Claude Code determines a model’s context window and auto-compaction threshold from an internal table of known Anthropic model names. If you point it at a model ID, it doesn’t recognize it, like muse-spark-1.3-contributor, and instead of erring out, it silently defaults the auto-compact window to 1 token. The result: you type a single word and immediately get the context limit reached, because the CLI is now measuring your session against a 1-token budget instead of the model’s real window.

If you run /context all, you’ll see a compaction window that reads 1 token (default for an unrecognized model), with normal-looking usage numbers (system prompt, tools, skills) suddenly reported as usage percentages in the hundreds of thousands.

Muse Spark 1.3 Contributor actually has a native ~1,048,576-token (1M) context window, larger than Claude’s default 200K assumption. The fix is the same suffix Claude Code uses to opt Anthropic’s own 1M-capable models into their extended window:

export ANTHROPIC_MODEL="muse-spark-1.3-contributor[1m]"

Appending [1m] tells Claude Code to treat the model as having a 1-million-token window and to add the context-1m behavior it normally reserves for Sonnet/Opus 1M variants, instead of falling back to the broken 1-token default. Officially, this suffix is documented only for known Anthropic model names, using it against a custom model ID is a workaround, not a supported path, so treat it as something to verify with /context after every Claude Code update rather than a guarantee. If a future release changes how unrecognized models are handled, this could stop working (or start working differently) without notice.

Two more MCP-related notes worth checking after switching endpoints:

• Confirm your MCP tools still show as (loaded on-demand) in /context all rather than fully materialized. Some custom-gateway setups lose Claude Code’s deferred tool-schema loading, which inflates baseline context usage significantly. If you see full tool definitions listed as loaded rather than on-demand, that’s worth investigating separately from the [1m] fix above.

• ENABLE_TOOL_SEARCH="true" is worth setting alongside the above if your Claude Code build supports it, but verify it’s actually being honored for your endpoint; an unrecognized or ignored flag will silently do nothing rather than error.

Quick reference

# ~/.bashrc or a project-local .env
export MODEL_API_KEY="<your-meta-model-api-key>"
export ANTHROPIC_BASE_URL="https://api.meta.ai"
export ANTHROPIC_AUTH_TOKEN="$MODEL_API_KEY"
export ANTHROPIC_MODEL="muse-spark-1.3-contributor[1m]"
export ANTHROPIC_DEFAULT_OPUS_MODEL="muse-spark-1.3-contributor[1m]"
export ANTHROPIC_DEFAULT_SONNET_MODEL="muse-spark-1.3-contributor[1m]"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="muse-spark-1.3-contributor[1m]"
export CLAUDE_CODE_SUBAGENT_MODEL="muse-spark-1.3-contributor[1m]"

Then verify with claude, and immediately run /context all. If the compaction window reads a sane number instead of 1 tokens (default for an unrecognized model), you’re set up correctly.

If all is wired correctly, reload your shell and start the Claude code CLI. You should see muse-spark as the model name in use inside the Claude code.

Swap -contributor out of every model ID above if you’re working with anything you wouldn’t want Meta training on; the pricing difference is real, but so is what you’re trading for it.

At some point, adding another feature on top stops being progress.

Sometimes you have to go back and fix the foundations.

That is, in large part, what MantisBase v0.4 has become.

A little history

During the v0.2 → v0.3 transition, one of our goals was to standardize the API surface and establish a clearer contract for anyone building against MantisBase.

Part of that plan involved exposing the new APIs to JavaScript through Duktape. The bigger idea was not limited to JavaScript either: once we had a stable internal API, supporting other scripting languages would become considerably easier.

Unfortunately, the JavaScript work planned for v0.3 never really saw the light of day.

Why?

Because the underlying code was still moving too quickly.

We were making many seemingly small changes that affected routes, internal objects, authentication behavior, entity handling, and lifecycle management. Every one of those changes would then have needed to be mirrored in the JavaScript bindings.

That would have meant maintaining effectively two implementations of a rapidly changing API, and potentially repeating the same work again for every additional scripting language.

That did not make much sense.

Rather than continue adding bindings on top of an architecture we already knew needed work, we decided to address the underlying problems first.

What problems were we running into?

A few issues kept showing up during development and testing.

Realtime connections did not scale particularly well

Until v0.4, MantisBase used cpp-httplib extensively for both normal HTTP traffic and Server-Sent Events (SSE).

SSE is intentionally a long-lived HTTP connection. A client connects, and that connection stays open while the server pushes database changes back to it.

The problem with our implementation was that every active SSE connection occupied a server thread.

With a handful of clients, this was not particularly noticeable.

With enough clients, however, those long-lived connections could consume the available worker threads. Normal REST requests would then sit waiting for a worker to become available.

In other words, realtime traffic could eventually prevent the server from serving regular HTTP traffic.

That is not a particularly useful property for something calling itself a backend.

The global singleton had become expensive

MantisBase historically exposed much of the application through a global singleton.

It was convenient.

Until it wasn’t.

Global state made lifecycle management difficult, made ownership less obvious, and caused headaches in the testing harness. Starting and stopping multiple instances within the same process could result in stale state, shutdown-order issues, memory problems, and occasionally spectacular crashes.

It also worked against one of MantisBase’s longer-term goals: being genuinely useful as an embeddable C++ library.

If somebody embeds MantisBase into a desktop application, daemon, embedded device, test environment, or another larger system, they should control the lifetime of the MantisBase instance.

A hidden global object should not control it for them.

The API was becoming harder to extend safely

The scripting work exposed another problem.

An API that changes frequently is expensive to bind.

If adding JavaScript, Python, Lua, or another language requires duplicating large parts of MantisBase internals, every change becomes progressively more expensive.

Before expanding the extension system, we therefore needed to make the C++ side cleaner first.

That became one of the guiding ideas behind v0.4:

Make MantisBase easier to embed, extend, test, and operate before piling more features on top.

So, what have we been cooking?

Quite a bit.

What’s changing in v0.4?

1. Goodbye, global singleton

We have officially dropped the global MantisBase singleton.

This is probably not the flashiest v0.4 feature, but internally it is one of the most important changes.

Instances now have much clearer ownership and lifecycle semantics. That makes testing considerably easier and creates a much better foundation for embedding MantisBase inside other C++ applications.

Instead of assuming that exactly one magical MantisBase instance exists somewhere in global state, the application can explicitly create, configure, use, and destroy an instance.

Boring architectural changes are often the ones that unlock the interesting features later.

This is one of those changes. You can read more details about this change in our previous post here.

2. Authentication is expanding

Authentication has received quite a bit of attention.

The first stage of OAuth support has landed. It is still relatively new and needs considerably more real-world testing, so consider it early support rather than a finished OAuth story.

We have also added API keys.

This is particularly useful for automation, services, scripts, CI jobs, agents, and AI-driven workflows where an interactive username/password login flow does not make much sense.

API keys can be created for administrative accounts as well as regular authentication accounts, allowing machine-to-machine clients to interact with MantisBase without pretending to be an interactive user.

There is more work to do here, but this gives us a much better foundation for non-human clients.

3. A new HTTP backend

This is probably the most consequential runtime change in v0.4.

We have migrated the underlying HTTP server from cpp-httplib to Drogon.

The biggest motivation was concurrency.

As described earlier, our previous SSE implementation tied each long-running realtime connection to a worker thread. At sufficient concurrency, realtime subscriptions could therefore starve ordinary HTTP requests.

Drogon’s asynchronous networking model gives us considerably more room to handle long-lived connections without treating every connection as a permanently occupied worker.

The change also opens another realtime option:

WebSockets.

SSE remains useful, especially because it is simple, works over HTTP, and is perfectly adequate for many database subscription use cases, but WebSockets are now available as an alternative for applications that need bidirectional communication or want to maintain a persistent realtime channel.

This migration was not simply swapping one HTTP library for another. A large amount of route handling, middleware behavior, authentication plumbing, request/response handling, realtime infrastructure, and testing had to move with it.

That is part of why v0.4 has taken the shape it has.

4. ARM Linux builds

Linux ARM support has been added to our builds.

MantisBase has always been particularly interesting to us outside the traditional “deploy another service into Kubernetes” use case.

A relatively small, self-contained backend makes sense on development machines, edge systems, local appliances, desktop applications, Raspberry Pis, and other small Linux devices.

ARM support is therefore an important part of making that story practical rather than theoretical.

There will inevitably be hardware and distro combinations we have not tested, so feedback here is especially welcome.

5. Simpler data types

We have simplified MantisBase’s data-type system.

One particularly noisy area was integer types.

Rather than exposing a collection of conceptually similar integral types as completely independent MantisBase types, integer fields now use a simpler int model with precision describing the actual representation—for example u8, u16, u32, i8, through to i64.

The intention is to keep the schema easier to reason about without losing control over representation when that precision matters.

We have also removed the old xml and blob types.

The general direction here is deliberate: fewer special cases, a smaller schema vocabulary, and clearer behavior.

Every type we expose becomes something that has to be supported consistently across SQLite, PostgreSQL, REST serialization, validation, migrations, scripting, the admin UI, and eventually language bindings.

A smaller, well-defined type system is considerably easier to keep correct.

6. Developer packages

Starting with the v0.4 release line, release artifacts now include developer packages containing both the static and shared MantisBase libraries for the platforms we build.

This matters if you do not want to run MantisBase purely as a standalone server.

You might want to:

• embed it into an existing C++ application;

• build your own server around the MantisBase core;

• add functionality that does not belong upstream;

• experiment with alternative scripting integrations; or

• use parts of MantisBase as infrastructure within another project.

The standalone binary is still the easiest way to get started.

The developer package is for everyone who eventually asks:

“Okay, but can I use MantisBase inside my application?”

Increasingly, the answer should be yes.

7. Security hardening

As the API surface has grown, we have also spent considerably more time looking at how those APIs behave when clients are actively hostile rather than merely buggy.

Recent security-hardening work has covered access control, OAuth verification, realtime authorization, SQL/schema validation, file serving and uploads, rate limiting, HTTP security headers, error handling, and container deployment.

Some of those changes are intentionally stricter and may expose assumptions in existing deployments.

That is a tradeoff we are willing to make while v0.4 is still in prerelease.

It is much better to discover and fix those assumptions now than to permanently preserve unsafe behavior because somebody might already depend on it.

If you are testing the v0.4 prereleases, this is one area where feedback is especially valuable.

Try the weird things.

Try the things you think should fail.

And if they do not fail, tell us.

8. Documentation rewrite

A lot of the documentation had fallen behind the codebase.

That happens surprisingly quickly during periods of heavy architectural work: endpoints change, CLI commands move, examples refer to previous response formats, and suddenly the docs describe a product that only partially exists anymore.

We have been going through the documentation and bringing it back into parity with the current codebase.

This includes reorganizing documentation, updating API responses and examples, fixing installation instructions, and filling in missing sections.

The v0.4 releases have already included several rounds of documentation fixes and restructuring.

Documentation is still a work in progress, so if you encounter something that disagrees with the actual application, please open an issue.

9. More configuration knobs

We have also expanded runtime configuration.

More behavior can now be controlled using environment variables, making it easier to configure MantisBase in Docker and other deployment environments without maintaining custom configuration files.

Some features and behaviors can be explicitly enabled or disabled depending on how you intend to run the server.

Check the Docker and configuration documentation for the current set of options—the list is still evolving during the v0.4 prerelease cycle.

A few development hacks

If you are building MantisBase yourself, there are a couple of quirks worth knowing about.

Prefer Release-with-Debug-Info for debugging

For development builds, we currently recommend building with release optimizations plus debug information rather than using a full Debug configuration on GCC.

Some Debug builds can run into stack-related problems.

You still get useful symbols for debugging without paying all of the costs associated with the full Debug configuration.

Use dynamic linking while iterating

Static linking is useful for release binaries because it helps us ship a portable package with minimal runtime dependencies.

It is considerably less fun when you are making a tiny source change and rebuilding repeatedly.

For local development, enable dynamic linking where appropriate. Build-test-debug cycles become much faster, and you can switch back to the static configuration when validating a release-style build.

Check the CMake options for the relevant switches.

PostgreSQL on Windows is still missing

PostgreSQL support is not currently shipped on Windows.

Static linking PostgreSQL and all of the associated dependencies into a clean Windows release remains an interesting little adventure.

SQLite works, of course.

PostgreSQL-on-Windows is something we still need to revisit.

No macOS build yet

We are also not shipping a macOS build at the moment.

The main reason is considerably less interesting than some deep technical incompatibility:

I do not currently have a Mac available for properly developing, testing, and maintaining the build.

Rather than publish an artifact we cannot confidently test, macOS will have to wait for now.

Contributions here are very welcome.

So, is v0.4 ready?

Not quite.

And that is why the releases are labelled alpha and beta.

At the time of writing, v0.4.0-beta.2 is available as a GitHub prerelease.

These builds exist specifically so that we can find the remaining rough edges before calling v0.4 stable.

If you have been curious about MantisBase, this is actually a particularly useful time to try it.

Run an application against it.

Embed the library.

Open too many realtime connections.

Try OAuth.

Use API keys from an automation.

Run it on ARM.

Throw malformed requests at it.

Build it using a toolchain we probably forgot existed.

Break it.

That feedback is far more valuable during beta than after a stable release.

For Docker users, the prerelease images are available under the corresponding v0.4 tags.

Where we go from here

v0.4 contains visible features, but the more important changes are underneath them.

Removing global state makes embedding and testing easier.

Changing the HTTP backend gives realtime connections a better foundation.

Simplifying the type system reduces the number of edge cases every future integration must support.

Developer libraries make MantisBase useful as more than a standalone executable.

Authentication and API keys make service-to-service and automation workloads more practical.

And all of that makes the scripting story we originally wanted to build considerably more realistic.

That last part is important.

JavaScript support was not abandoned because scripting stopped being interesting.

We paused it because building language bindings against unstable foundations would have multiplied our maintenance work.

With v0.4, we are trying to make those foundations boring.

Stable objects. Clear ownership. Predictable APIs. Better concurrency. Smaller interfaces.

Once those pieces settle, JavaScript—and potentially other scripting languages—becomes a much more manageable problem.

Help us break it

MantisBase is open source, and v0.4 is still being shaped.

If you try the prerelease, we would love to hear:

• what worked well;

• what broke;

• what was confusing;

• what you expected to exist but could not find;

• where the documentation disagreed with reality;

• and what you think MantisBase should tackle next.

Open an issue or start a GitHub Discussion. We also have a Discord server now for longer-form conversations, questions, experiments, and project updates.

And, of course:

Star it. Fork it. Build it. Break it. Fix it.

Contributions of every size are welcome.

v0.4 has involved considerably more rebuilding than we originally expected.

But sometimes the fastest way forward is to stop adding floors and reinforce the foundation first.

That is what we have been cooking.

Many Autodesk products include components or dependencies that rely on Microsoft .NET technologies. As part of this commitment to providing highly trustworthy and performant software, Autodesk product teams are planning updates to Autodesk products, where applicable and feasible, to align with Microsoft’s .NET product support lifecycle.

3ds Max 2026, Maya 2025, and Maya 2026 have already rolled out security updates that include an upgrade from .NET 8 to .NET 10. Refer to the respective product release notes for more information:

• 3ds Max 2026 Release Notes

• Maya 2026 Release Notes

• Maya 2025 Release Notes

Note: 3ds Max 2024/2025 and Maya 2024 use .NET Framework 4.8 variants and therefore do not require this .NET 10 upgrade. Microsoft continues to support .NET Framework 4.x versions, including 4.8 and 4.8.1, in accordance with the lifecycle of the Windows operating system on which they are installed. .NET Framework will also continue to be included with Windows. Read more about supported .NET Frameworks here.

Also note: 3ds Max 2027 and Maya 2027 ship with .NET 10 by default, so no changes are required for these versions.

As a result of these upgrades, we recommend ensuring that all related Autodesk products are also updated to avoid potential compatibility issues.

For additional background, see our previous blog post here.

What do you need to do?

There are no API changes in any of these products as part of this update. The only change is that the underlying .NET runtime is moving from .NET 8 to .NET 10.

Existing plug-ins and add-ins should continue to work unless they are affected by breaking changes introduced in .NET 10. In such cases, they may need to be recompiled and retargeted to .NET 10.

Developers are advised to test their plug-ins and add-ins for compatibility with the updated product releases.

If you encounter any compatibility issues, please report them through ADN Support.

Related links

• Autodesk Products: What customers need to know about Microsoft .NET 10 updates

• 3ds Max: Requirements for products affected by the Microsoft .NET 10 transition

• Maya: Requirements for products affected by the Microsoft .NET 10 transition

• Breaking changes in .NET 10

Also posted here: https://blog.autodesk.io/microsoft-net-10-updates-for-autodesk-3ds-max-and-maya/

There was just one problem. The Python version was built on MaxPlus, and MaxPlus is gone (deprecated and removed from 3ds Max 2022).

This post walks through how we brought the sample back, what changed when we moved it onto the modern pymxs + PySide6 stack, and a few things we improved along the way.

The Explode Geometry dialog (screenshots will be refreshed for the new PySide6 UI).

A quick history lesson

MaxPlus was the first official Python binding for 3ds Max, introduced back in 2014. It exposed a hand-curated, object-oriented wrapper over the C++ SDK, classes like MaxPlus.TriObject, MaxPlus.Factory, and MaxPlus.NotificationManager.

It was useful, but it was also a maintenance burden: every class and method had to be wrapped by hand, so coverage was always partial and always lagging the SDK. Meanwhile, pymxs, which exposes the full MAXScript runtime to Python, kept growing into the more complete, better-supported option.

So MaxPlus was deprecated in 3ds Max 2021 and removed entirely starting with 3ds Max 2022. Any sample that imports MaxPlus stops loading; thus the classic Explode Geometry sample sat abandoned because the port wasn’t trivial: MaxPlus and pymxs think about the scene very differently.

The original sample is still in the repo as explode_geometry_classic.py for historical reference. It’s a good before/after companion to everything below, but note it only runs on 3ds Max 2016–2021.

The goals of the port

We set out to do more than merely make it run again:

1. Drop every MaxPlus dependency and target 3ds Max 2022+ (best on 2026/2027).

2. Move the UI to PySide6, the Qt6 binding shipped with modern 3ds Max.

3. Keep feature parity with the .NET sample’s options — shell, edit-mesh, collapse, centre-pivot, delete-original, and the TriMesh/MNMesh choice.

4. Improve the experience while we were in there: a real progress bar, an undoable operation, a debug toggle, and timing feedback.

Wiring the window into 3ds Max

MaxPlus had its own helpers for parenting a Qt widget to the Max main window and making it dockable:

# Classic (MaxPlus) 
form.setParent(MaxPlus.GetQMaxWindow()) 
MaxPlus.MakeQWidgetDockable(form, 4) 

The modern equivalent uses the qtmax module that ships with 3ds Max, plus a standard Qt window flag:

# New (qtmax + PySide6) 
form.setParent(qtmax.GetQMaxMainWindow()) 
form.setWindowFlags(QtCore.Qt.WindowType.Tool) 
form.show() 

qtmax.GetQMaxMainWindow() returns the real QMainWindow for Max, so the dialog behaves like a native tool window — it stays on top of Max and follows it as expected.

Listening for selection changes

The classic sample registered a selection callback through MaxPlus’ notification manager and tore it down by index:

# Classic 
MaxPlus.NotificationManager.Register( 
 MaxPlus.NotificationCodes.SelectionsetChanged, self.updateSelectionLabel) 
... 
MaxPlus.NotificationManager.Unregister(MaxPlus.NotificationManager.Handlers[-1]) 

With pymxs, we go straight to the MAXScript callback system, which is both more capable and easier to clean up because we can tag callbacks with a named ID:

# New 
rt.callbacks.addScript(rt.Name(’selectionSetChanged’), 
 self.updateSelectionLabel, 
 id=rt.Name(’explodeGeom’)) 
... 
rt.callbacks.removeScripts(id=rt.Name(’explodeGeom’)) 

Naming the callback group allows us to remove everything under explodeGeom when the Qt dialog closes.

The TriMesh path: from low-level mesh to one call

The classic sample built each face by hand against the low-level mesh API, casting to a TriObject, grabbing the Mesh, setting vertex and face counts, copying verts, and invalidating the geometry cache:

# Classic — manual mesh construction 
new_face = MaxPlus.Factory.CreateNewTriObject() 
n = MaxPlus.Factory.CreateNode(new_face) 
mesh = new_face.GetMesh() 
mesh.SetNumFaces(1) 
mesh.SetNumVerts(3) 
mesh.GetFace(0).SetVerts(0, 1, 2) 
mesh.GetFace(0).SetEdgeVisFlags(1, 1, 1) 
mesh.GetFace(0).SetSmGroup(2) 
for i in range(0, 3): 
 pt = tri_mesh.GetVertex(face.GetVert(i)) 
 mesh.SetVert(i, pt) 
mesh.InvalidateGeomCache() 

With pymxs we lean on the MAXScript mesh() constructor, which takes vertices and faces directly. The whole per-face body is collapsed to a few lines:

# New — high-level mesh constructor 
rt.convertToMesh(node) 
num_faces = rt.getNumFaces(node) 
for face_idx in range(1, num_faces + 1): 
 face = rt.getFace(node, face_idx) 
 v1 = rt.getVert(node, int(face.x)) 
 v2 = rt.getVert(node, int(face.y)) 
 v3 = rt.getVert(node, int(face.z)) 
 
 new_node = rt.mesh(vertices=rt.Array(v1, v2, v3), 
 faces=rt.Array(rt.Point3(1, 2, 3))) 
 rt.update(new_node) 
 new_node.wireColor = _random_wire_color() 
 applySettings(new_node, addShell, shell_amount, 
 addEditMesh, collapseNode, centerPivot) 

No manual cache invalidation, and the new node lands in the scene automatically. As a small visual nicety, we also assign each exploded face a random wire colour so you can actually see the individual pieces.

The MNMesh path: detach instead of rebuild

The classic MNMesh path was the most painful code in the old sample. To make each polygon, it created a PolyObject, reached into the MNMesh, set vertex/edge/face counts, positioned every vertex, built a visibility list, called MakePoly, then FillInMesh, roughly 20 lines of low-level construction per face.

The pymxs version sidesteps all of it. Instead of rebuilding each face as a new poly, we let polyop.detachFaces do the work and hand us back a node directly:

# New — let polyop detach each face into its own node 
rt.convertToPoly(node) 
num_faces = rt.polyop.getNumFaces(node) 
for face_idx in range(num_faces, 0, -1): 
 rt.polyop.detachFaces(node, rt.Array(face_idx), asNode=True) 
 new_node = rt.objects[-1] 
 new_node.wireColor = _random_wire_color() 
 applySettings(new_node, addShell, shell_amount, 
 addEditMesh, collapseNode, centerPivot) 

A couple of details worth noting:

• We iterate backwards (num_faces … 1). Detaching a face renumbers the remaining faces, so walking from the end keeps the indices we haven’t processed yet stable.

• asNode=True makes detachFaces create a brand-new node for the detached face, which we then grab as rt.objects[-1].

This is dramatically simpler, and it leans on Max’s own, well-tested geometry code instead of our hand-rolled mesh building.

MNMesh mode: each polygon is detached into its own node.

Applying the modifiers

The applySettings helper is conceptually identical between versions — the difference is just how you instantiate a modifier. MaxPlus used the factory and a parameter block:

# Classic 
mod = MaxPlus.Factory.CreateObjectModifier(MaxPlus.ClassIds.Shell) 
mod.ParameterBlock.outerAmount.Value = shell_amount 
n.AddModifier(mod) 

In pymxs, modifiers are just runtime classes you call like constructors, and their parameters are plain attributes:

# New 
mod = rt.Shell() 
mod.outerAmount = shell_amount 
rt.addModifier(n, mod) 

The same pattern covers Edit_Mesh, maxOps.collapseNode, and centerPivot (it reads almost as the MAXScript).

What we added beyond parity

Since we are rewriting it anyway, why not make the tool better? Here are some quality of life improvements we baked in:

Undo as a single operation. Exploding a model creates a lot of nodes. Wrapping the whole run in a pymxs.undo block means a single Ctrl+Z reverts the entire explode instead of unwinding it one face at a time:

with pymxs.undo(True, “Explode Geometry”): 
 ... # all node creation/deletion happens here 

A real progress panel. Exploding a dense mesh can take a while, so the dialog now shows a progress bar plus the current node name and an N of M counter. This matches the .NET dialog with a progress bar. The conversion functions take an on_progress callback and pump QApplication.processEvents() so the UI stays responsive:

def _prog(cur, tot): 
 self.progress_bar.setValue(int(cur * 100 / tot) if tot else 0) 
 QtWidgets.QApplication.processEvents() 

A debug toggle. Rather than littering the code with print calls, we route everything through Python’s logging module to the MAXScript Listener. A “Show Debug Messages” checkbox flips the logger between WARNING and DEBUG.

Note: Verbose logging affects performance, especially around hot paths and loops when there are many nodes/faces to explode. The completion summary is always printed regardless of the toggle.

Timing feedback. We wrap the run with time.perf_counter() and report how long the explode took — handy when you’re comparing the TriMesh and MNMesh paths on the same model.

pymxs.print_(”[ExplodeGeometry] Explode completed in {:.2f} seconds.\n”.format(elapsed)) 

Python 2 to Python 3, while we’re here

The classic sample was Python 2 (note the print msg statements and the Qt4-era PySide/QtGui imports). The port is clean Python 3 on PySide6: QtWidgets instead of QtGui, pymxs.print_() for Listener output, and modern signal connections like checkStateChanged.

Shipping it as an AppBundle

Running a script from the editor is fine for development, but the sample also ships as a proper Automatic Loader AppBundle under Bundle2/, so it can show up as a menu entry right next to the .NET version. The package’s Contents/python/ folder carries explode_geometry.py, and a small macroscript launches it:

macroScript ADNExplodeGeomPyMS 
  category:"ADN Samples"
  tooltip:"Explode Geometry (Python)" 
  buttonText:"Explode Geometry (Python)"
( 
 local scriptDir = getFilenamePath (getSourceFileName()) 
 local pyFile = scriptDir + "..\python\explode_geometry.py"
 python.ExecuteFile pyFile 
) 

How do we run the AppBundle?

You have two ways to get 3ds Max to load the bundle:

• Copy it into an auto-discovered plug-in folder. 3ds Max automatically scans the ApplicationPlugins directories on startup. Drop the Bundle2 folder (renamed to something like ADN-ExplodeGeometry.bundle) into one of:

  • %PROGRAMDATA%\Autodesk\ApplicationPlugins (all users), or

  • %APPDATA%\Autodesk\ApplicationPlugins (current user).

• Point an environment variable at it. Set ADSK_APPLICATION_PLUGINS to the folder containing your bundle before launching Max — handy when you’re iterating and don’t want to copy files around.

#Set ENV var (check terminal specifics for PowerShell/CMD/etc)
set ADSK_APPLICATION_PLUGINS=D:/path/to/bundle/parent/dir

# Launch mamax in the same shell
3dsmax.exe 

See the 3ds Max developer docs on the Plug-in Package (.bundle) format and PackageContents.xml for the full directory layout and the auto-loader search paths.

Once the bundle loads cleanly, you’ll find the tool on the main menu under App Store → Explode Geometry (Python), sitting alongside the original Explode Geometry (.NET) entry. Select your objects, launch it, and you'll see the same dialogue you’d see in the editor.

Not ethat the Python menu entry is part of the GitHub sample, but won’t show if you install the plugin from the AppStore.

One nuance worth knowing: the Python menu entry is only registered on 3ds Max 2027 and up. The post-start-up menu script gates it on the Max version:

-- Only add the Python menu entry for 3ds Max 2027+ (maxVersion 29000), 
-- where Python support in the menu system is available. 
if (maxVersion())[1] >= 29000 then 
( 
 newSubMenu.CreateAction "85045470-A03C-45EC-A13F-538346AF077A" 647394 "ADNExplodeGeomPyMS`ADN Samples" 
) 

The .NET action is added on all supported versions; the Python one is for 2027+ only.

A note on Qt versions

The sample is written against PySide6 (Qt 6), which is what ships with 3ds Max 2026 and 2027 — so on those releases it runs as-is.

On 3ds Max 2022–2025, the bundled Qt is the PySide2 (Qt 5) generation, so the imports and a few API details won’t match out of the box. If you want to run it there, you’ll need to adjust things like:

• from PySide6 import ... → from PySide2 import ...

• Scoped enums back to flat ones — e.g. QtCore.Qt.WindowType.Tool → QtCore.Qt.Tool.

• Signal differences — e.g. the Qt6 checkStateChanged signal versus Qt5’s stateChanged.

• QDialog/QMessageBox.exec() versus the older exec_().

None of these is hard, but they’re version-specific. Consider it a good exercise in learning where PySide2 and PySide6 diverge and a reminder always to check which Qt your target Max ships before writing UI code.

Lessons learned

A few takeaways for anyone facing a similar MaxPlus migration:

• pymxs is usually less code, not more. The instinct is to fear that dropping a “high-level” wrapper means more boilerplate. In practice, the opposite was true — rt.mesh(...) and polyop.detachFaces(..., asNode=True) replaced dozens of lines of manual construction.

• Prefer Max’s own operations over rebuilding geometry. The biggest simplification came from detaching faces instead of reconstructing them. When the SDK already does the thing you want, use it.

• Watch index invalidation. Anything that adds or removes faces/nodes mid-loop can shift the indices under you. Iterating in reverse is a cheap fix.

• qtmax is your friend for UI hosting. GetQMaxMainWindow() plus a Tool window flag gives you a well-behaved dialog without MaxPlus’ dockable helpers.

Try it out

The ported sample lives in the Explode Geometry repository under Python/explode_geometry.py. There are two ways to run it:

• Straight from the editor — open Python/explode_geometry.py in the 3ds Max scripting editor and execute it. Quickest for poking at the code.

• As an AppBundle — load the Bundle2/ package as described above and launch it from App Store → Explode Geometry (Python) (2027+).

Either way: select an object (or several), pick TriMesh or MNMesh, choose your options, and hit Explode. Then enjoy a single Ctrl+Z to put it all back together. It runs as-is on 3ds Max 2026/2027; for 2022–2025 you’ll need the PySide2 tweaks noted above.

The original .NET plug-in was written by Kevin Vandecar, from an idea by Louis Marcoux. The first Python version was developed by Drew Avis. This pymxs port modernises that work for 3ds Max 2022 and beyond.

Original posting here: https://blog.autodesk.io/setting-up-3ds-max-2027-sdk-development-with-visual-studio-2026/

What does the 3ds Max 2027 SDK require?

Per the official SDK Requirements page, 3ds Max 2027 targets:

The SDK Requirements page lists the IDE version as VS2022 17.14.13, but what your build must match is the MSVC v14.38 (17.8) toolset within the v143 family — see the next section for why that difference matters. Any edition of Visual Studio (Community, Professional, or Enterprise) can build 3ds Max plugins; the edition doesn’t matter, the toolset version does.

The SDK Requirements page names Visual Studio 2022 17.14.13 as the IDE baseline, but the build itself is pinned to a specific MSVC v143 build-tools version — v14.38 (17.8), which Microsoft now marks as Out of Support. “v143” is not a single compiler; it’s a family that spans many MSVC minor versions (14.30 through 14.44 and beyond), and 3ds Max 2027 is ABI-locked to the v14.38 set. The platform-toolset name stays v143 across Visual Studio 2022 and Visual Studio 2026 for backward compatibility, but the minor version underneath is what has to match.

This is why Visual Studio 2026 can host 3ds Max 2027 development: the newer IDE is able to install and target the older, out-of-support v14.38 build tools side by side with its own. 3ds Max and its plugins are extremely sensitive to ABI (Application Binary Interface) matching; a plugin must be built with a toolchain binary compatible with the one Autodesk used to build 3ds Max itself. Installing and selecting the v14.38 toolset is what keeps you inside that compatible window while still letting you run the newer IDE.

NOTE: The new IDE is fine; the exact build-tools version is what must match. Build against the v14.38 (17.8) v143 toolset, not whatever newer toolset Visual Studio 2026 installs by default.

What does Visual Studio 2026 ship with?

A default Visual Studio 2026 installation will not build a 3ds Max 2027 SDK project. Out of the box, VS2026 ships:

• the MSVC v14.44 build tools (the current v143 compiler), and

• the Windows 11 SDK 10.0.26100.x.

3ds Max 2027, by contrast, is built against the MSVC v14.38 (17.8) v143 build tools and the Windows 10 SDK 10.0.19041.0. Both VS2026’s defaults are newer than what the SDK expects, and that’s enough to break the build. To make matters more confusing, the v14.38 (17.8) toolset is now marked Out of Support by Microsoft, so it’s tucked away in the installer’s Individual components list rather than offered by default.

So, you must add the exact pieces Autodesk validated, and they come from two different places:

• MSVC v143 — VS 2022 C++ x64/x86 build tools (v14.38-17.8) — through the Visual Studio installer’s Individual components (under Out of Support).

• Windows 10 SDK (10.0.19041.0) — this one is not in the VS2026 installer at all. You download and install it separately, from the older-version downloads on the Windows SDK site.

The newer IDE can host the older, ABI-compatible v14.38 toolchain side by side with its own v14.44. But “possible” still means “you have to install it deliberately and then point your project at it.” The next section is exactly that; install the right pieces, then pin the project to them.

How to set up VS2026 for 3ds Max 2027

Assumptions and prerequisites

• A licensed copy of 3ds Max 2027 installed (you need a real install to test your plugin and to point to your debugger at 3dsmax.exe).

• The 3ds Max 2027 SDK installed.

• Qt 6.8.3 (the LGPL build) if your plugin uses Qt-based UI. Match this version exactly.

• .NET 10 SDK if you build managed or mixed-mode (C++/CLI) assemblies.

Install the right Visual Studio workloads and components

In the VS2026 installer, select the workloads:

• Desktop development with C++.

• .NET desktop development, if you build any managed components.

The workload alone is not enough, you need two more pieces, and they’re installed differently:

1. The v14.38 build tools — from the Visual Studio installer. Open the installer, switch to the Individual components tab, and use the search box to type v14.38. The matching entry — MSVC v143 - VS 2022 C++ x64/x86 build tools (v14.38-17.8) — appears under the Out of Support group; the installer will warn that it’s unsupported. That’s expected. Tick it and install it.

   

2. Windows 10 SDK 10.0.19041.0 — as a separate download. This version is not offered in the VS2026 installer. Download it on its own from the Windows SDK downloads site and run that installer. Once installed, it becomes selectable as a target SDK in your project.

Installing the 3ds Max plugin project wizard

The SDK ships an AppWizard that adds a “3ds Max Plugin” template to Visual Studio’s New Project dialog, pre-filled with the include paths, libraries, and project structure a plugin needs. It was written for Visual Studio 2022, but the setup for VS2026 is essentially works, you just copy the wizard files into the VS2026 IDE directory instead of the VS2022 one.

The wizard lives in:

3ds Max 2027 SDK\maxsdk\howto\3dsmaxPluginWizard\

Open the readme.txt in that folder and follow its steps, with one substitution: wherever it points you at the Visual Studio 2022 IDE directory, use the VS2026 IDE directory instead (the path where VS2026 is installed, under its Common7\IDE location). Copy the wizard’s .vsz / .vsdir and template files to the locations the readme describes, restart Visual Studio, and the 3ds Max plugin template appears in the New Project dialog.

Create, Build, load, verify

Similar to VS2022 workflow, create projects utilizing the Plugin Wizard for 3ds Max 2027. Projects generated still default to the correct v143 toolset.

Build and Run in Hybrid| x64, and confirm your plugin appears and loads cleanly.

If all was configured correctly, you should build successfully and 3ds Max should start and load the plugin.

Tips and tricks

Start from the SDK samples. The 3ds Max 2027 SDK ships sample projects that are already configured correctly. Building one of them first verifies your environment before you po

Always cross-check exact version numbers against the official 3ds Max 2027 SDK Requirements page before you commit your build configuration — point releases can shift toolsets and Windows SDK expectations.

It made sense at the time. There is exactly one server, listening on exactly one port, owning one database pool, one router, and one logger. Why wouldn’t there be one global handle to reach it all? For most of v0.1 through v0.3, that instinct served us well. In v0.4.x we are pulling the cord, replacing MantisBase::instance() with plain old dependency injection. This post is about why, and it’s worth starting with what a singleton actually is before explaining why we’re purging ours.

A quick detour through design patterns

If you’ve written software for any length of time you’ve absorbed design patterns whether or not you’ve read the book Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, Helm, Johnson & Vlissides, 1994). Patterns are not language features or libraries; they’re names for shapes that keep recurring. Having a shared vocabulary is genuinely useful: “wrap it in a decorator” communicates a whole structure in three words.

And then there’s Singleton.

The Singleton pattern “ensures a class has only one instance and provides a global point of access to it.” Two promises in one sentence, and the second one is the problem. It’s the only creational pattern in the book that most of its own authors would now tell you to avoid. In a 2009 interview, Erich Gamma — one of the four — said plainly:

“When discussing which patterns to drop, we found that we still love them all. (Not really, I’m in favor of dropping Singleton. Its use is almost always a design smell.)”

— Erich Gamma

The reason he gives is the reason this post exists.

How MantisBase became a singleton

MantisBase is an embeddable backend, a BaaS you link into a C++ process and drive. The MantisBase class is the composition root: it owns every subsystem and hands them out.

class MANTISBASE_API MantisBase
{
public:
    static MantisBase& instance();
    static MantisBase& create(const json& config = json::object());

    [[nodiscard]] Database& db() const;
    [[nodiscard]] Router& router() const;
    [[nodiscard]] Logger& logs() const;
    [[nodiscard]] RealtimeDB& rt() const;

    // ...

private:
    MantisBase();                       // creation is private
    static MantisBase& getInstanceImpl();
    std::atomic<bool> m_isCreated = false;
};

The mechanics are the textbook version. The constructor is private, `create()` builds the one instance, and `instance()` hands it back:

MantisBase &MantisBase::instance() {
    auto &app_instance = getInstanceImpl();
    if (!app_instance.isCreated())
        throw std::runtime_error("MantisBase not created yet");

    return app_instance;
}

MantisBase &MantisBase::create(const json &config) {
    auto &app = getInstanceImpl();
    if (app.isCreated())
        throw std::runtime_error("MantisBase already created, "
                                 "use MantisBase::instance() instead.");

    // ...
}

Even our own header documented the constraint as a feature:

Once that door is open, the whole codebase walks through it. Reaching the database from a request handler, a model, an auth check, or a file path resolver—all of it collapses into one convenient line:

// src/core/api_keys.cpp
auto sql = MantisBase::instance().db().session();

// src/core/files.cpp
return fs::path(MantisBase::instance().dataDir()) / "files";

// src/core/sse_mgr.cpp
auto &router = MantisBase::instance().router();

At last count, that pattern appeared across dozens of translation units, and that ubiquity is exactly the trap. Every one of those call sites is a dependency that doesn’t appear in any signature. Which brings us to why we’re ripping it out.

Why we’re ripping it out

1. A singleton is a global variable, dressed nicely

The case against globals is old and settled. Wulf and Shaw made it in 1973 in “Global Variable Considered Harmful”: non-local access makes it impossible to reason about a piece of code in isolation, because any part of the program can influence any other through the shared name. A singleton doesn’t repeal that argument; it just dresses it in a class with a `static` accessor. As Miško Hevery put it in his widely cited critique, Singletons are Pathological Liars: the method signature lies to you. When a `apiKeyLookup(id)` secretly calls `MantisBase::instance().db()`, its true dependency list is nowhere in its declaration. You only discover it by reading the body or by watching it explode at runtime.

This is the Dependency Inversion Principle (the “D” in Robert C. Martin’s SOLID) inverted the wrong way: our high-level model and request code depended directly on a concrete global-access mechanism instead of on abstractions handed to them.

2. The testing harness had to bend around it

This is where the abstraction stopped being free. Because there can only ever be one instance per process, our entire test suite is built around a single global application that must be stood up once and shared by everything. Look at what the test environment has to do:

// tests/common/test_environment.h
inline MbTestEnv::MbTestEnv() {
    // ... assemble config ...
    mb::MantisBase::create(args);          // the one and only create()
}

inline void MbTestEnv::SetUp() {
    serverThread = std::thread([this]() {
        server_running.store(true);
        auto res = mb::MantisBase::instance().run();   // reach back for it
    });

    // sleep, poll /health, hope it came up...
}

Every test then reaches through the same global to get at subsystems:

// tests/unit/test_database.cpp
EXPECT_TRUE(mb::MantisBase::instance().db().isConnected());

// tests/unit/test_models.cpp
mb::EntitySchema base{mb::MantisBase::instance(), "test", "base"};

The consequences are exactly what Michael Feathers warns about in Working Effectively with Legacy Code (2004). He defines a unit test as one that runs fast and in isolation, but singletons destroy isolation by construction. Global state persists between tests, so ordering matters, and you get to write defensive code like this just to survive a `create() > close() > create()` cycle within a single process:

// src/mantisbase.cpp

// Start from a clean slate: on a create() -> close() -> create()
// cycle (e.g. across test runs in one process) the arg vector would
// otherwise accumulate the previous run’s arguments.

app.m_cmdArgs.clear();
app.m_cmdArgs.emplace_back("mantisbase");

That comment is a remnant record of the pain, a state that should have died with an object instead outlives it, because the object is a `static` that never really goes away. Freeman and Pryce, in Growing Object-Oriented Software, Guided by Tests (2009), argue that hard-to-test code is usually a signal of a design problem, not a testing problem. The singleton was our signal, printed in every `instance()` call the tests had to make.

3. We now genuinely need more than one instance per process

The convenience argument for a singleton, “there’s only ever one”, turned out to be false as the product grew. We want to run multiple independent MantisBase instances in a single process: think isolated tenants, an embedding host driving several databases, or simply a test that spins up two servers and asserts they don’t leak into each other. We already have the test that describes the goal:

// tests/integration/test_integration_multi_instance.cpp

TEST_F(MultiInstanceTest, IndependentEntitiesDontInterfere) {
    // create schema multi_inst_a and multi_inst_b, insert into each,
    // and assert each entity sees exactly its own row.
    EXPECT_EQ(body_a["data"]["items_count"], 1);
    EXPECT_EQ(body_b["data"]["items_count"], 1);
}

You cannot express “two independent apps that don’t interfere” when `instance()` is hardwired to return the one true app and `create()` throws the second time you call it. The singleton isn’t just inconvenient here; it makes the requirement unrepresentable.

What we’re replacing it with

The fix is the boring, correct one that Martin Fowler catalogued back in 2004 in Inversion of Control Containers and the Dependency Injection pattern constructor injection. Instead of reaching out to a global, each object is handed the app it belongs to, at construction, as its first parameter.

A locked-in design decision for v0.4.x: the app is the first constructor parameter, so nobody can forget to bind it.

// include/mantisbase/core/http.h

class MantisRequest {
    /// Owning application, injected by the Router when the request is
    /// wrapped. Request-path code reaches shared services (db, router,
    /// realtime, config) via app() instead of the global singleton.

    const MantisBase &m_app;

public:
    explicit MantisRequest(const MantisBase& mb, const drogon::HttpRequestPtr& req);
    const MantisBase& mApp() const { return m_app; }
};

// include/mantisbase/core/models/entity.h
Entity(const MantisBase &app, const nlohmann::json &schema);
Entity(const MantisBase &app, const std::string &name, const std::string &type);

`Router`, `Database`, `Entity`, `EntitySchema`, `SSEMgr`, `WSMgr` each now takes its owning `MantisBase&` up front and stores it. The dependency that used to be invisible is now right there in the signature, allowing the type to tell the truth about what it needs.

The refactor isn’t finished. A handful of `instance()` calls in infrastructure code—the logger, file utilities, date helpers, the SSE manager, and one validator—are deliberately still standing, development in progress (maybe done by the time you are reading this!).

The lesson from v0.4.x isn’t that singletons are bad. It’s that convenience at the composition root has a way of becoming a constraint at the leaves. `MantisBase::instance()` saved us a constructor parameter thousands of times and charged interest on every one. Dependency injection just makes you pay the cost up front, in the open, where the type system can see it, and that turns out to be the cheaper deal.

This work is part of the ongoing MantisBase v0.4.x line. If you want to follow along, check out the v0.4.x branch and watch out for exciting features coming soon!

Why the change?

As MantisBase grew, the API surface accumulated small inconsistencies. Auth took the target entity in the request body while everything else was path-based. File serving lived at `/api/files/...` while the rest of the API was versioned under `/api/v1/`. Admin operations were split awkwardly between the auth namespace and the system namespace.

v0.3.6 makes the whole surface predictable. Everything now lives under `/api/v1/` in a clear set of namespaces:

Authentication is now per-entity

Previously you told MantisBase which entity to authenticate against by putting it in the request body:

# Old (v0.3.5)
curl -X POST http://localhost:7070/api/v1/auth/login \
  -H "Content-Type: application/json" \
  -d '{"entity": "users", "identity": "user@example.com", "password": "pw"}'

Now the entity lives in the URL, which is more RESTful and lets each auth entity have its own clearly addressable endpoints:

# New (v0.3.6)
curl -X POST http://localhost:7070/api/v1/auth/users/login \
  -H "Content-Type: application/json" \
  -d '{"identity": "user@example.com", "password": "pw"}'

The same pattern applies to refresh and logout:

curl -X POST http://localhost:7070/api/v1/auth/users/refresh \
  -H "Authorization: Bearer <token>"

curl -X POST http://localhost:7070/api/v1/auth/users/logout \
  -H "Authorization: Bearer <token>"

The `<entity>` must be a registered `auth`-type entity that isn’t a system table and has the API enabled — otherwise you’ll get a clean `404 Route Not Found`.

One more thing: the login response is now wrapped in MantisBase’s standard envelope, so it matches every other endpoint:

{
  "status": 200,
  "data": {
    "token": "eyJhbGci...",
    "user”: { "id": "123456"”, "email": "user@example.com", "name": "John Doe" }
  },
  "error": ""
}

Admins get their own namespace

Admin authentication and account management now live entirely under `/api/v1/sys/admins/`, and admin CRUD is fully supported:

# Create the very first admin (only works when none exist yet)
curl -X POST http://localhost:7070/api/v1/sys/admins/setup \
  -H "Content-Type: application/json" \
  -d '{"email": "admin@example.com", "password": "adminpassword"}'

# Admin login
curl -X POST http://localhost:7070/api/v1/sys/admins/login \
  -H "Content-Type: application/json" \
  -d '{"identity": "admin@example.com", "password": "adminpassword"}'

# Manage admin accounts (requires admin auth)
curl http://localhost:7070/api/v1/sys/admins                   # list
curl http://localhost:7070/api/v1/sys/admins/:id               # get one
curl -X POST   http://localhost:7070/api/v1/sys/admins ...     # create
curl -X PATCH  http://localhost:7070/api/v1/sys/admins/:id ..  # update
curl -X DELETE http://localhost:7070/api/v1/sys/admins/:id     # delete

The old `POST /api/v1/auth/setup/admin` endpoint is gone — use `/api/v1/sys/admins/setup` instead.

Files and settings

File serving is now versioned, matching the rest of the API:

# Old:  http://localhost:7070/api/files/posts/photo.jpg
# New:  http://localhost:7070/api/v1/files/posts/photo.jpg

curl http://localhost:7070/api/v1/files/posts/photo.jpg

And application settings are exposed under the system namespace:

curl http://localhost:7070/api/v1/sys/settings/config   # read
curl -X PATCH http://localhost:7070/api/v1/sys/settings/config \
  -H "Content-Type: application/json" -d '{ ... }'             # update

Under the hood: lighter on memory

Beyond the visible API changes, we refactored how routes are registered. Instead of building a dedicated set of CRUD handlers for every single entity, MantisBase now uses centralized, generic handlers that resolve the target entity from the request path. Schema route handlers were similarly decoupled from the schema object. The result is the same behavior with a smaller memory footprint — especially noticeable on deployments with many entities.

We also refreshed the bundled dependencies (WolfSSL, nlohmann/json, jwt-cpp, spdlog, and the mb-admin dashboard) and fixed a build-target clash around `ztd`.

Something is broken, oh no!

As a result of the API changes, we ended up breaking the admin dashboard. Currently, v0.3.6 admin dashboard is unusable and requires reworking to bring it up to bar. That’s already being worked on and we will push an update once resolved.

Upgrading from v0.3.5

Most apps only need three mechanical updates:

1. Auth calls: move the entity from the body into the path
   (`/api/v1/auth/login` + `"entity": "users"` → `/api/v1/auth/users/login`).

2. Admin calls: repoint admin auth/setup to `/api/v1/sys/admins/...`.

3. File URLs: add the 1 segment (`/api/files/...` → `/api/v1/files/...`).

If you parse the login response, unwrap it from the new `{ status, data, error }` envelope.

That’s it — grab v0.3.6 from the releases page, and check the updated Authentication API and API Reference docs for the full details.

Then, somewhere around the third month, the project stalls. Not dramatically — there’s no postmortem, no cancellation email. It just quietly stops moving. The remaining work never gets easier, the Rust never gets good, and eventually the branch goes stale.

This isn’t a failure of nerve or tooling. It’s a structural property of what porting C++ to Rust actually is — and it’s worth understanding before you spend a quarter learning it the expensive way.

The seduction is real, and so is the wall

The reason the demo is so convincing is that the first 90% genuinely is easy now. Translating C++ control flow, arithmetic, and data structures into syntactically valid Rust is exactly the kind of pattern-matching LLMs are good at. The compiler even helps: if it builds, a lot of bugs are already gone.

The problem is what’s hiding in the last 10%, and it’s the same thing whether a human or a model is doing the work.

C++ does not encode ownership. When you write T* p, the language does not record whether p owns that memory, borrows it, shares it, or aliases something else that’s about to be freed. Those facts live in the programmer’s head, in comments, in naming conventions, and in tribal knowledge about “who frees what.” Rust’s entire value proposition is that these facts must be written down and checked. So a C++→Rust port is not a translation. It’s a reconstruction of invariants that were never explicitly recorded.

That’s why automatic transpilers are so instructive. Tools like c2rust produce Rust that is “almost always correct” — and almost always unsafe and unidiomatic. They faithfully preserve C’s pointer semantics by wrapping everything in unsafe, raw pointers, and libc calls. The output compiles. It is also, in the words of the research, “very different from the kind of Rust code usually written by humans, making it hard to read and maintain” — and it sails straight past the linters that are supposed to catch the problems. You get Rust syntax with C semantics: all of the migration cost, none of the safety payoff.

LLMs improve on this — they can sometimes infer ownership and produce idiomatic code — but the failure mode is sneakier. As DARPA’s program manager for TRACTOR (the agency’s program to automate exactly this translation) put it: ask any model to translate C to safe idiomatic Rust and “something comes out, and it’s often very good, but not always.” When it’s not, the model tends to reach for unsafe to make the borrow checker stop complaining — which is precisely how you end up with code that looks migrated but carries the same latent bugs it always had, now harder to spot because everyone assumes “it’s in Rust, so it’s safe.”

This is the mechanism behind the stall. The borrow checker doesn’t get tired and wave the last 10% through. Every place where the original C++ had a fuzzy ownership story becomes a hard stop that requires a human to decide what the ownership story should be — and frequently to redesign the data structures to express it. That’s design work, not typing work. LLMs removed the typing bottleneck, which was never the bottleneck.

The evidence cuts both ways — but cleanly

The honest read of the industry data is not “Rust good” or “rewrites bad.” It’s that the shape of the project predicts the outcome far better than the language choice does.

Look at what the wins have in common. Android never ported anything — Google’s entire strategy is that new code is Rust and old C++ is left in place; the safety gains come from the fact that “most bugs live in new code”, so you don’t need to touch the old stuff to bend the curve. Pingora wasn’t a translation at all; it was a clean-room reimplementation against a known spec, where the team got to design the ownership model from scratch instead of recovering it from someone else’s pointers. Mozilla picked off self-contained, parallelism-hungry components one at a time and integrated each before starting the next.

Now look at curl. Daniel Stenberg’s team spent roughly five years (2020–2025) trying to let curl use the Rust hyper library as an HTTP backend through an FFI glue layer — and ultimately ripped it out. The reasons are a near-perfect catalog of why these projects die:

• The last 5% was the whole problem. “The final few percent would turn out to be friction enough to now eventually make us admit defeat.”

• Nobody to do the hard part. It needed someone fluent in both C and Rust and the HTTP protocols to drive the integration across the FFI boundary — and almost no one wanted to.

• The FFI seam leaked. They had to remove HTTP/2 support because they’d misunderstood how the API integrated across the language boundary.

• No demand pulling it forward. curl users didn’t care that a backend was in Rust; Rust users didn’t want to maintain glue for a C project.

Stenberg’s conclusion is the bluntest data point in the whole debate: “We’re not going to rewrite curl in Rust. In any language — we’re not going to rewrite it at all.” This from someone who openly acknowledges that roughly half of curl’s historical vulnerabilities are C memory mistakes. He knows the safety case cold. He’s declining anyway, because the migration cost is real and the existing C is hardened by decades of fuzzing and CVE wrangling.

The hidden tax: comprehension debt

There’s a second-order cost that the demo never shows you, and it’s worse with LLM-driven ports than with hand ports.

When a model emits 4,000 lines of plausible Rust, no one on your team owns the mental model of that code. The 2025 research on LLM-generated code calls this comprehension debt and “ownership debt”: “it compiles” is not the same as “someone understands why it’s correct and can change it safely.” With a hand-written port, the engineer who fought the borrow checker comes out the other side understanding the ownership model — that understanding is half the point. With a generated port, you’ve skipped the understanding and kept only the artifact. The first time it needs a non-trivial change, you pay the comprehension cost you deferred, except now under deadline and without the person who’d have built the model.

This is why “the LLM did 90% in a week” is a misleading metric. The week of typing was never the expensive part. The expensive part is owning a correct mental model of a safety-critical system — and that’s exactly what gets skipped when the code arrives pre-written.

A decision framework that actually predicts outcomes

Stop asking “should we port to Rust?” It’s the wrong altitude. Ask these instead:

1. Is this new code or existing code?

If new, strongly favor Rust, and stop reading. The Android data is overwhelming: the cheapest safety win is to stop adding to the C++ pile. No migration risk, all the upside.

2. If existing — is the component self-contained, or is it threaded through the codebase?

A module with a narrow, well-defined interface (a parser, a codec, a proxy data path) is a Stylo/Pingora candidate. A module whose pointers reach into everything will trap you in FFI hell: every call across the C++/Rust seam is an unsafe boundary where Rust’s guarantees evaporate and new bugs breed. The curl/hyper failure was fundamentally an FFI-boundary failure.

3. Do you have a spec, or only the code?

If you can reimplement against a specification or a strong test suite (Pingora had the HTTP spec; you can have a differential test harness), favor a clean-room rewrite over a line-by-line port. You’ll design the ownership model instead of reverse-engineering it, and you can run old and new side by side to prove equivalence.

4. Will someone own the result?

If the answer is “the LLM wrote it and we’ll figure it out later,” you don’t have a migration plan, you have a future incident. Budget the human comprehension cost up front or don’t start.

5. Is the existing C++ actually your risk?

Battle-hardened, heavily-fuzzed C++ that hasn’t thrown a CVE in years is not where your memory-safety risk concentrates. New and frequently-changed code is. Spend the migration budget where the bugs actually are.

The verdict

Use the LLM. It genuinely removed a real cost — the mechanical translation that used to make these projects unaffordable to even start. But understand precisely what it removed and what it didn’t. It removed the typing. It did not remove the thinking: recovering ownership invariants that C++ never recorded, designing data structures that satisfy the borrow checker, and proving the result is equivalent to the original.

That thinking is the project. It was always the project. The reason ports stall at 90% is that the demo completes the 90% that was never hard, and then hands you the 10% that was the entire point — now disguised as “almost done.”

Port new code by default. Port self-contained components against a spec. Leave hardened, stable C++ alone. And treat any plan whose timeline is built on “the model already wrote most of it” as a plan that hasn’t started yet.

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.

Originally posted here:

Explore New Features in 3ds Max 2027 Release Updates

A few weeks ago, 3ds Max 2027 was officially released, introducing new features and capabilities for both artists and developers. With this release, 3ds Max saw many upgrades including Arnold to 5.9.0, USD to 0.14.0, Substance to 3.0.6, performance improvements across tools, modifiers, and render workflows, and much more. Refer to the product release page for a detailed feature breakdown for 3ds Max 2027.

New Features, Improvements, and Updated Workflows

3ds Max 2027 ships with several notable updates across its plugin ecosystem: 

• Arnold for 3ds Max updated to 5.9.0 (Arnold 7.5.0.0)

• USD for 3ds Max updated to 0.14.0

• Substance updated to 3.0.6

• Autodesk Assistant (Technical Preview): An AI-powered tool that helps you quickly find information about features and workflows directly within the product — a welcome addition for developers and artists alike looking to streamline their pipeline research. Read more here.

SDK Changes

Now let's get into what matters most for plugin developers.

• .NET 10.0 Support: 3ds Max 2027 moves plugin development to .NET 10. Note that .NET 8, introduced in 3ds Max 2026, has reached an end of life and is no longer supported. If you are still on an older version, refer to our porting guide from .NET Framework to .NET for plugins for step-by-step migration guidance.

• DirectX 9 Removal: Support for DirectX 9 has been fully removed. This affects several headers that have been dropped from the public SDK — notably id3d9graphicswindow.h, idx9pixelshader.h, and idx9vertexshader.h — along with related interfaces in ihardwarematerial.h, ihardwarerender.h, and RTMax.h. Developers relying on these should migrate to the DirectX 11 equivalents now available in the SDK.

• Updated Core Dependencies: 3ds Max 2027 development specifies Visual Studio 2022 (v17.14.x), C++20, Qt 6.8.3. Review your plugin dependencies against these versions before building. You could also use the newer Visual Studio 2026, when you set the toolset to be v143.

• API Changes: There are targeted API updates across several headers — including new methods in custcont.h, ioapi.h, and IValidateNodeCallback.h, as well as deprecations in object.h, gfx.h, and others.

• Updated Samples and Documentation: Samples and documentation have been updated to reflect all API changes in this release.

We're shipping v0.3.4 today with a handful of quality-of-life improvements, a cleaner configuration story, and a few important bug fixes. Here's what's new.

Unified MB_* Environment Variable Prefix

All environment variables now consistently use the MB_* prefix. If you were previously setting MANTIS_JWT_SECRET, update that to MB_JWT_SECRET — the old name is no longer recognised. This brings every runtime knob under one coherent namespace and makes it easier to manage configuration in Docker and CI environments.

Variable Description Default MB_JWT_SECRET JWT signing secret (set this in production!) built-in default MB_DISABLE_FILE_UPLOADS Set to 1 to disable file uploads globally 0 MB_DISABLE_ADMIN_ON_FIRST_BOOT Set to 1 to skip auto-admin creation browser spin off 0 MB_DISABLE_RATE_LIMIT Set to 1 to disable rate limiting enabled

File Upload Kill Switch

A new MB_DISABLE_FILE_UPLOADS=1 flag lets you turn off file uploads at the server level without touching your schema. Any upload attempt while this flag is active will receive a 403 Forbidden response. Useful for read-only deployments or environments where you want to enforce that no files land on disk.

Docker Improvements

The Dockerfile has been updated to debian:trixie-slim as its base, and the build arg has been renamed from MANTIS_VERSION to MB_VERSION (default 0.3.4) to match the new naming convention. The docker-compose file now also surfaces all MB_* variables as commented-out stubs, so it's clear what you can configure without digging through docs.

The published image on Docker Hub is allankoech/mantisbase — the quick-start command is simply:

docker run -p 7070:80 allankoech/mantisbase

All submodules have also been switched from SSH to HTTPS URLs and set to shallow fetch, which significantly speeds up fresh clones in CI pipelines.

Admin Panel Updates

Several improvements have landed in the admin UI this release:

Entity cloning — You can now clone an existing entity directly from the admin panel. Cloning copies the source entity's schema (field names, types, and structure) into a new entity, giving you a clean starting point to build on without recreating common field sets from scratch. No records are carried over, only the schema.

Entity renaming — Entities can now be renamed from within the admin panel without having to drop and recreate them.

Long entity name overflow fix — Entity names that exceeded the available sidebar/panel width were pushing other UI elements off screen. This has been corrected so long names truncate gracefully and the layout stays intact.

Minor bug fixes and improvements across the admin panel generally.

Bug Fixes

• PATCH requests with password fields — a missing-field error that surfaced when patching records containing a password field has been resolved.

• Last-activity tracking — activity timestamps now only update on actual database record changes, not on every SSE ping or passive connection event. This prevents misleading "active" signals for idle clients.

• SSE session cleanup — auth tokens are no longer held in memory on SSE sessions. The token field is explicitly nulled out after verification, reducing the risk of credentials lingering in heap memory across a long-lived connection.

Internal / Code Quality

• soci_wrappers.h saw a significant cleanup — redundant nesting in the field-binding logic was flattened, making the type-dispatch code considerably easier to follow.

• SSE event queuing now uses emplace instead of push for slightly cleaner construction.

• SQL update column formatting moved to std::format for consistency.

Upgrading

Update your environment variables from MANTIS_JWT_SECRET → MB_JWT_SECRET and pull the new image or rebuild from source. No schema migrations are required for this release.

The full changelog and binaries are available on the GitHub releases page.

If you've been following along, you know I've been busy building MantisBase for a while now. Today feels like a good checkpoint to step back, write a bit, and share what's shipped.

This is the first official devlog. There will be more.

The Project Website is Up

First things first, MantisBase now has a proper home on the internet.

MantisBase | Lightning fast BaaS in C++

It's a landing page for now, but it does the job — gives you a quick feel for what MantisBase is and where it's headed. If you've been curious but haven't dug into the GitHub repo yet, the website is probably the gentler starting point.

Try It Without Installing Anything

This one I'm particularly happy about.

One of the biggest friction points with any self-hosted tool is the "I'll check it out later" trap; you bookmark it, tell yourself you'll spin it up over the weekend, and then never do. I've been guilty of this myself more times than I'd like to admit.

So we now have a live demo environment:

Mantis Admin Dashboard

No installation. No Docker. No config files. Just open it and poke around. If it clicks for you, then you can go down the setup rabbit hole.

Docker Image on Docker Hub

Speaking of setup—for those who are comfortable with Docker and just want to pull and run, we've got you covered.

docker pull allankoech/mantisbase

Full image available at:

allankoech/mantisbase - Docker Image

This is probably the fastest path from zero to a running instance if you're on a server or just want to keep things clean on your local machine.

What's Next

We're currently in the middle of cleaning up the admin UI — ironing out some rough edges and squashing a few bugs that have been on the list. Nothing dramatic, just the kind of polish work that makes the difference between something that works and something that feels solid.

More updates soon. If you want to follow along, the GitHub repo is the most up-to-date place to track progress.

Until the next devlog. ✌️

February 4, 2026 — We're excited to announce the release of MantisBase v0.3.3, bringing real-time database capabilities to this lightweight, high-performance Backend-as-a-Service framework. This release introduces Server-Sent Events (SSE) support for both SQLite and PostgreSQL backends, along with critical bug fixes and improved system observability.

What's New in v0.3.3

Real-Time Database via SSE

The flagship feature of v0.3.3 is native real-time database synchronisation using Server-Sent Events. Unlike traditional polling approaches that waste resources checking for updates, SSE establishes a persistent HTTP connection that allows the server to push changes to clients as they happen.

Why SSE?

Server-Sent Events offer several advantages for real-time database applications:

• Efficient unidirectional streaming — Perfect for database change notifications where data flows primarily from server to client

• Built on standard HTTP — No special protocols or WebSocket infrastructure required

• Automatic reconnection — The browser's EventSource API handles connection recovery automatically

• Firewall-friendly — Works through corporate proxies and firewalls that might block WebSocket connections

• Low overhead — Simpler than WebSockets when you don't need bidirectional communication

Universal Backend Support

Real-time updates now work seamlessly with both SQLite and PostgreSQL databases. Whether you're running MantisBase on an embedded device with SQLite or scaling up with PostgreSQL, you get the same real-time capabilities without changing your code.

Enhanced System Observability

System logs have been moved to a dedicated database and are now accessible through the /api/v1/logs endpoint, providing administrators with powerful filtering and pagination capabilities for monitoring and debugging.

Getting Started with Real-Time

Opening an SSE Connection

Connect to the real-time endpoint and subscribe to entity changes:

// Subscribe to changes on the 'posts' entity
const eventSource = new EventSource(
  'http://localhost:7070/api/v1/realtime?topics=posts'
);

// Listen for all events
eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log('Received event:', data);
};

// Handle connection events
eventSource.onopen = () => {
  console.log('SSE connection established');
};

eventSource.onerror = (error) => {
  console.error('SSE connection error:', error);
  // Browser automatically reconnects
};

Subscribing to Multiple Entities

You can monitor multiple database entities on a single connection:

// Subscribe to posts, comments, and users
const eventSource = new EventSource(
  'http://localhost:7070/api/v1/realtime?topics=posts,comments,users'
);

eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  
  // Events include the entity name they originated from
  switch(data.entity) {
    case 'posts':
      updatePostsUI(data);
      break;
    case 'comments':
      updateCommentsUI(data);
      break;
    case 'users':
      updateUsersUI(data);
      break;
  }
};

Event Format

Real-time events follow a consistent JSON structure:

{
  "type": "INSERT",
  "entity": "posts",
  "data": {
    "id": "abc123",
    "title": "New Post Title",
    "content": "Post content here",
    "created": "2026-02-03T14:30:00Z",
    "updated": "2026-02-03T14:30:00Z"
  },
  "timestamp": "2026-02-03T14:30:00.123Z"
}

Event Types:

• INSERT — New record created

• UPDATE — Existing record modified

• DELETE — Record removed

Dynamic Topic Management

Update your subscriptions without reconnecting:

// Later, add more topics to the existing connection
async function subscribeToComments() {
  await fetch('http://localhost:7070/api/v1/realtime', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `Bearer ${yourAuthToken}`
    },
    body: JSON.stringify({
      client_id: clientId,
      topics: ['posts', 'comments']  // Updated topic list
    })
  });
}

// Or clear all subscriptions
async function unsubscribeAll() {
  await fetch('http://localhost:7070/api/v1/realtime', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `Bearer ${yourAuthToken}`
    },
    body: JSON.stringify({
      client_id: clientId,
      topics: []  // Empty array clears all topics
    })
  });
}

System Logs API

Access and monitor system logs with the new logs endpoint:

# Get recent logs (requires admin authentication)
curl -H "Authorization: Bearer <admin_token>" \
  http://localhost:7070/api/v1/logs

# Filter by log level
curl -H "Authorization: Bearer <admin_token>" \
  "http://localhost:7070/api/v1/logs?level=ERROR"

# Pagination
curl -H "Authorization: Bearer <admin_token>" \
  "http://localhost:7070/api/v1/logs?limit=50&offset=100"

# Filter by time range
curl -H "Authorization: Bearer <admin_token>" \
  "http://localhost:7070/api/v1/logs?from=2026-02-03T00:00:00Z&to=2026-02-03T23:59:59Z"

Migration Guide

If you're upgrading from v0.3.2, here's what you need to know:

Breaking Changes

There are no breaking changes in v0.3.3. The real-time API is a new addition that doesn't affect existing functionality. To enrol existing entities to be real-time "enabled", update the entities to trigger the real-time monitoring.

Security Considerations

Authentication for Real-Time

Real-time connections respect MantisBase's access control rules:

• For public topics (entities), no additional authentication is required.

• For non-public entities, the following rules are enforced:

  • List Rule: Used to list records in an entity.

  • Get Rule: Used to fetch a record by the record ID.

For non-public entities, provide the authorisation JWT token when creating the EventSource stream.

Installation & Upgrade

Download Pre-built Binaries

Download the latest release from GitHub Releases:

# Linux
wget https://github.com/allankoechke/mantisbase/releases/download/v0.3.3/mantisbase-linux-x64.zip
unzip mantisbase-linux-x64.zip
chmod +x mantisbase
./mantisbase serve

# Windows
# Download mantisbase-windows-x64.zip and extract
mantisbase.exe serve

Build from Source

git clone --recurse-submodules https://github.com/allankoechke/mantisbase.git
cd mantisbase
git checkout v0.3.3
cmake -B build
cmake --build build
./build/mantisbase serve

Bug Fixes

This release includes several important bug fixes:

• Fixed memory leak in SSE connection handling

• Improved database connection pooling for PostgreSQL

• Resolved race condition in concurrent entity updates

• Fixed authentication token refresh timing

• Corrected CORS headers for cross-origin real-time connections

Community & Support

Join our growing community:

• GitHub: github.com/allankoechke/mantisbase

• Documentation: allankoechke.github.io/mantisbase

• YouTube Tutorials: MantisBase Playlist

• Discussions: GitHub Discussions

• Support: Patreon

Acknowledgments

Thank you to everyone who contributed to this release through bug reports, feature requests, and code contributions. MantisBase is built for developers, by developers.

Checkout the video announcement here:

MantisBase—Lightning-fast BaaS in C++. One binary, full backend, anywhere.

For the full changelog, see v0.3.2...v0.3.3

The second edition of the Smart Living & Tech Leadership Conference 2025 ran for two days, with intense, future-focused dialogue. Day one set the foundation — sustainability, leadership, and the evolving role of cities in shaping human experience. Talks centred on energy management, mobility systems, and the ethics of digital transformation.

Day two shifted toward design, technology, and AI, unpacking how digital tools turn ideas into smarter, more liveable environments.

The Core Idea

Smart living isn’t about gadgets. It’s about intentional design. Every decision — spatial, structural, or digital — shapes how we live, move, and connect. Design is the link between people, data, and sustainability.

🗨️ "Design is not just what it looks like and feels like. Design is how it works."
— Steve Jobs

Steve Jobs was a visionary who foretold of what it became of today, a fusion of design and functionality. A move toward designing for use rather than designing for aesthetics alone.

My Session: Smart Living by Design

I presented “Smart Living by Design: Evolving from Digital Tools to AI Decisions.” The session traced design’s evolution—from manual drafting to data-driven modelling and now to intelligent, AI-augmented systems.

• Digital tools like Revit, Inventor, 3ds Max, and Maya redefined collaboration and precision.

• AI now extends creativity — generating forms, predicting outcomes, and guiding sustainable choices.

• Projects like Bernini show how AI-driven 3D generation can reduce waste and optimise performance.

• Digital twins enable continuous feedback loops between the real and virtual worlds, making smart cities adaptive by design.

The key takeaway: AI doesn’t replace creativity — it amplifies it. The future designer leads with intent, while AI accelerates exploration and insight.

Conversations That Followed

Post-session discussions were rich. People wanted to know how data models support interoperability across industries and where the limits of AI automation should be drawn. Others shared case studies on generative layouts for housing, mobility planning, and carbon analysis.

Outside the panels, the networking felt natural. Designers, engineers, urban planners, and educators connected over one shared vision — building systems that think with us, not for us.

Closing Thought

The conference reinforced a simple truth: design is leadership. Tools evolve, but human intention drives change. If we design with purpose — aligning creativity, technology, and sustainability — smart living becomes not an idea, but a lived reality.

Join the conversation!

Qt is a mature and feature-rich framework, but building flexible and declarative UIs often requires more than widgets and signals. That’s where Slint fits in. It provides a compact, declarative syntax for building modern UIs while staying native and lightweight.

Some Qt-based projects, like LibrePCB, already use Slint to modernise their UI without abandoning their existing Qt foundation. Check the full blog details here. Embedding Slint lets you:

• Keep your Qt app logic and backend code intact.

• Use Slint for fast, declarative, and maintainable UI layers.

• Mix and match Slint views with traditional Qt widgets.

• Gradually migrate UI parts without a full rewrite.

Watch the walkthrough video here:

Slint UI 102: Embedding Slint UI Within a Qt Application | C++

What you’ll learn:

• How to embed Slint UI components in a Qt app

• How to compile .slint files to native C++

• How to synchronise data between Qt and Slint

• How to manage event flow and cleanup

Resources:

• Slint Documentation: https://slint.dev/docs

• Slint Source Code: https://github.com/slint-ui/slint

• Slint C++ Template: https://github.com/slint-ui/slint-cpp-template

• Full Source Code from this video: https://github.com/allankoechke/qt-slint-integration-cpp

We have earlier introduced Mantis, a C++ BaaS toolkit, designed to be lightweight but powerful.

Introducing Mantis: The C++ Backend Framework Built for Simplicity and Speed

What's changed?

From our last v0.2.7 release a couple of weeks ago, we have some important fixes and improvements added to our v0.2.8 release. Have a look:

• PostgreSQL Support: v0.2.8 brings full PostgreSQL support for Linux builds. This allows for easy backend database switch when scaling is required while maintaining lightweight backend database (SQLite) where it's needed. How do you switch the database? Easy!

• Minor bug fixes & improvements: Lots of bugs were squashed, solving some performance issues as well as mending some issues that existed. Chief among these is matching data types compatibility for SQLite to/from PostgreSQL, forcing SQLite WAL mode checkpointing for every boot and refactoring project for performance improvements.

Release Release v0.2.8 · allankoechke/mantis

Getting Started?

We have a YouTube video to guide you out; don't fret. Checkout the video below for a walkthrough of the features mantis provides. If you have any question, lets discuss on YouTube or open a GitHub issue.

Enjoy!

We’ve shipped Mantis v0.2.7-beta, a new milestone for our lightweight pluggable backend-as-a-service (BaaS) framework written in C++. This release focuses on making file management a first-class feature while continuing to strengthen stability and prepare for broader database support.

Highlights

File and Files Field Support

• Records now support file and files fields.

• Upload, update, and remove files directly through record operations.

• Safer filename handling with sanitization for long names and unknown characters.

For more information on how to handle files in Mantis, check out the docs below:

mantis/doc/11.files.md at master · allankoechke/mantis

Health check Endpoint

• Added a /api/v1/health endpoint to make it easier to monitor and integrate Mantis into production setups.

Mantis Admin v0.1.7

• Updated to the latest version of the Mantis Admin dashboard with file management capabilities.

• Improved performance in the admin panel when working with larger datasets.

Bug Fixes and Improvements

• Better handling of database value binding with soci::values.

• Performance optimization for table ID generation.

• More consistent cleanup of file references for updates and removals.

PostgreSQL Support (WIP)

• Early integration of PostgreSQL via SOCI.

• Initial support for builds, CLI commands, and CI/CD integration.

• Still marked experimental but progressing quickly.

⚠️ PostgreSQL support is experimental and currently only built for Linux. The feature still has unresolved issues and may fail to launch entirely.

Why It Matters

Mantis is designed as an alternative to Firebase, Supabase, or PocketBase, but lighter, portable, and embeddable directly into your C++ applications. By keeping the runtime minimal and the architecture pluggable, we aim to make backend services faster to integrate and easier to run anywhere.

What’s Next?

• Complete PostgreSQL support for production use.

• Expanded file access controls.

• More integrations for different deployment targets.

Get Started

GitHub Repo: https://github.com/allankoechke/mantis
Release Page: https://github.com/allankoechke/mantis/releases/tag/v0.2.7-beta
Documentation: https://docs.mantisapp.dev/.

Feedback is welcome. If you try out the new file support or start testing PostgreSQL integration, please let us know how it works for you.

In a world dominated by heavyweight frameworks and bloated deployment pipelines, Mantis stands out as a fast, modular C++ backend library designed for simplicity, speed, and embeddability. Whether you're building for the cloud, desktop, or embedded systems, Mantis gives you modern backend capabilities with zero friction.

What Makes Mantis Special?

🚀 Single Binary Deployment

No containers, no dependencies, no problem. Mantis compiles to a single mantisapp binary that runs anywhere—just:

./mantisapp serve -p 8000

It’s ideal for embedded devices, desktop applications, or servers where simplicity is paramount.

Zero-Configuration REST APIs

Define your tables—and that’s it. Mantis auto-generates RESTful CRUD endpoints, complete with JWT-based authentication and fine-grained access control.

🧠 Minimal Runtime Footprint

With SQLite as the default database and tight memory usage, Mantis is engineered for environments where every byte counts.

Key Benefits That Set Mantis Apart

🔧 Embeddable by Design

Unlike traditional backends that require external deployment, Mantis can be embedded directly into your C++ application. Add backend functionality to Qt apps, CLI tools, or microservices—all from within your codebase.

🔐 Built-in Authentication & Security

Mantis handles token generation, validation, and route-level access control using JWT. You get secure, configurable auth out-of-the-box.

📊 Lightweight Admin Dashboard

Each Mantis deployment includes a built-in admin dashboard for managing tables, records, and users—no separate tooling or setup required.

🐳 Docker-Ready

Mantis offers a Docker image with volume mounting support, ideal for containerized environments and CI/CD pipelines.

🛠 Technology Stack

Mantis integrates robust C++ libraries to deliver production-grade performance:

• HTTP Server: httplib-cpp for lightweight HTTP(S) handling

• Database: SOCI as an abstraction layer (SQLite by default; MySQL/PostgreSQL coming soon)

• Authentication: l8w8jwt for secure token management

• Logging: spdlog for structured, high-performance logging

🚧 Future Vision: What’s Coming

Mantis isn’t just stable—it’s growing. Here’s what’s on the horizon:

• Real-Time Sync Engine
  WebSocket-powered data sync between clients and the backend—perfect for offline-first and collaborative apps.

• Full RDBMS Support
  Extend Mantis from SQLite to full support for MySQL and PostgreSQL with seamless migration tooling.

• Pluggable Middleware Architecture
  Customize request handling with user-defined middleware for logging, validation, authentication, or anything else.

Getting Started is Effortless

You can start using Mantis today in one of two ways:

Option 1: Use Prebuilt Binaries

Available for Linux (x86_64) and Windows (x64)—just download and run.

Option 2: Build From Source

If you're targeting another platform or want to embed Mantis into your own C++ application:

git clone --recurse-submodules https://github.com/allankoechke/mantis.git
cd mantis
cmake -B build
cmake --build build
./build/mantisapp serve -p 5000

Access the dashboard at http://localhost:5000/admin.

👉 Read the full setup guide here:
https://allankoechke.github.io/mantis/setup.html

🌟 Why Choose Mantis?

In a space filled with over-engineered solutions, Mantis offers a refreshing alternative: modern backend functionality in a compact, embeddable C++ package. Whether you're targeting embedded devices, developer tools, or just want a backend that won’t get in your way—Mantis delivers.

Ready to Try It?

Explore the GitHub repository, download the binaries, and see what lightweight backend development really feels like.

In the growing jungle of codebases, developer tools, and open-source libraries, one thing remains consistently frustrating: documentation. Whether they're too shallow, too outdated, or just missing altogether, bad docs slow everyone down. But what if you could talk to a codebase like you would a teammate? That’s where DeepWiki comes in.

DeepWiki | AI documentation you can talk to, for every repo

What’s DeepWiki?

It provides up-to-date documentation for any repo in the world that you can talk to. At first glance, you might consider it similar to your favorite LLM, but with the added context of a codebase.

💡 A wiki is a form of hypertext publication on the internet which is collaboratively edited and managed by its audience directly through a web browser. A typical wiki contains multiple pages that can either be edited by the public or limited to use within an organization for maintaining its internal knowledge base.

DeepWiki is powered by Devin AI, but over the past few months, there have been new open-source entrants to the space providing the same functionality.

Where does it find its use?

Consider this: the quality of documentation for repositories can range from excellent to inadequate. Imagine bumping into a repo with no docs, but it seems like a good fit for your needs. This scenario is where DeepWiki can help you create documentation for human understanding without needing to read through the entire codebase line by line.

You ask, it answers. From "What does this function do?" to "How does authentication work in this repo?" DeepWiki gives you direct, conversational insight based on the actual code, not assumptions.

It’s particularly useful when:

• You inherit a legacy code and need to quickly catch up.

• You're actively participating in open-source projects and seeking to understand the internal workings.

• You’re assessing a new library or tool and need to grasp its internals without reading 10 files.

But how does it work?

Behind the scenes, DeepWiki syncs with the repository and builds an internal understanding of the code—structure, logic, and behavior. It doesn’t just summarize; it contextualizes. Ask a question, and it doesn’t respond based on generic training but refers to the actual code. That’s the difference.

How do I get started?

It's actually quite simple. On any GitHub repo you need to look into, replace the GitHub with the DeepWiki domain. For instance, for the SQLite repo above, replace https://github.com/sqlite/sqlite to https://deepwiki.com/sqlite/sqliteand there you'll be ready to chat with your repo.

⚠️ Note that not all repos are already indexed. For those that aren't, you'll have to request indexing and provide your email, and you'll be notified once indexing is completed. Usually in less than an hour or so.

Why it matters

We’re entering a world where shipping fast isn't enough; you also need to understand fast. DeepWiki makes technical onboarding smoother, reduces context-switching, and adds clarity to chaos, especially in large or under-documented codebases.

Sure, it’s not a silver bullet. It won’t replace solid developer docs. But it’s a powerful fallback when the docs are missing, outdated, or nonexistent.

Final thoughts

In a way, DeepWiki brings back the original promise of AI in dev tooling—not to replace developers, but to augment them. It’s not just about code completion or chat-based assistance anymore; it’s about deep understanding. And in that space, DeepWiki has carved out something genuinely useful.

Whether you're delving deeply into a complex system or simply exploring a new library, DeepWiki is a valuable resource.

FAQs

1. What is DeepWiki, and how does it work?

DeepWiki is an AI-powered tool by Devin AI that generates real-time, conversational documentation for any code repository. It analyzes the codebase and lets developers ask natural language questions to understand functionality, architecture, and workflows.

2. Can DeepWiki document private or internal repositories?

Yes, DeepWiki can be used with private repositories as long as you grant it access. It can then generate documentation and allow conversational querying based on your internal codebase.

3. How is DeepWiki different from ChatGPT or other AI coding assistants?

While general AI assistants like ChatGPT are trained on broad programming knowledge, DeepWiki is built to ingest and understand specific repositories, offering contextual, code-aware responses tailored to your exact codebase.

4. Is DeepWiki useful for teams and enterprise-level development?

Absolutely. DeepWiki can dramatically speed up developer onboarding, reduce time spent searching through code, and improve collaboration by acting as a living, interactive documentation layer for your projects.

5. Does DeepWiki replace traditional documentation?

No, but it complements it. While human-written documentation provides structure and intent, DeepWiki helps fill gaps, explain code in real time, and answer questions dynamically—especially when traditional docs are missing or outdated.