The community maintains Fluxnova.
Nobody operates it for you.
Fluxnova is the FINOS distribution of the Camunda 7 engine, and it is healthy and actively maintained. What an open project does not give a regulated institution is release engineering, a signed distribution, migration execution and an accountable party at 2am. That is the part iTmethods operates.
Delivered as a single-tenant dedicated instance, in infrastructure iTmethods operates or in your own cloud account on AWS or Azure. Both are available today; Google Cloud is planned for 2027. Air-gapped and sovereign are in development.
Two migrations are on the table right now.
Which one you are looking at depends on where you already are, and they are not the same piece of work. One is a move off a dead edition. The other is a forced upgrade inside a live one.
Your process definitions are load bearing. Fluxnova is the compatible path, and the move is an infrastructure project before it is anything else. The migration path →
Version 3.0 moved Spring Boot and fourteen end-of-life libraries. Cockpit is being retired, and JBoss and WildFly support is ending. If you run either app server, this is a forced move rather than a planned one.
It is sponsored and contributed to by global financial institutions, and the project is public. The alternative on the table is a different vendor relationship rather than a different engine.
Release engineering, a signed distribution, patching on a cadence you agreed, and a named engineer when a process stops at 2am. That is the gap, and it is the whole of what this page is about.
Somebody has to design the process.
Reign Ops operates the engine. It does not design what runs on it. Summit58 does that work: process analysis and BPMN modeling, decision logic and DMN, agentic process and subprocess design, systems and data integration, and Camunda 7 to Fluxnova migration. Where their fixes are accepted upstream, the wider Fluxnova community gets them too. They design the process, we operate the platform, and neither of us is guessing about which is which.
— Ryan Johnston, Founder and Managing Principal, Summit58
We benchmarked it rather than asserting it.
An identical invoice process, one thousand workflow instances, run on Camunda 7, on Fluxnova and on Camunda 8, on matched infrastructure. The method and the raw results are published so you can judge how far they carry to your own models.
Read the denominator. This is our invoice process on our infrastructure, and it tells you about our invoice process. The method is published so you can judge how far it carries to yours; your models are not our models. The published method and results → · Run it on your own volumes →
What the engine looks like at production scale.
Two institutions run Fluxnova independently, with their own internal teams. They are not iTmethods customers and have not used Managed Fluxnova on Reign Ops. Their public remarks are cited here because they describe the engine, and the shared-service operating model, at the scale of the two largest known deployments.
Quoted from public conference remarks and attributed to the speaker and the event. Neither organization has expressed a view on Reign, and neither is a reference for it.
The engine will faithfully record what the agent did. It has no opinion on whether it should have.
Version 3.0 shipped MCP integration and agentic adhoc subprocesses. An agent can now invoke a process and determine its own steps at runtime, from a prompt and the business context. That is a capability of the engine, and it changes what a process instance is: an adhoc subprocess does not declare its steps in advance, so the record of what ran is no longer the same thing as a record of what was authorized.
Two shapes are available, and both are single-tenant.
Runs on the stack you already have. The instance is provisioned for one customer and serves that customer only, wherever it runs.
| Model | Status | What it is |
|---|---|---|
| Dedicated instance | Available today | A single-tenant instance in infrastructure iTmethods operates, connected securely to your estate. The faster start and the lower entry point. |
| Customer cloud | Available today | The same single-tenant instance deployed and operated inside your own cloud account on AWS or Azure. The account is yours and the billing relationship with the provider is yours. Google Cloud is planned for 2027. |
| Air-gapped | In development | No external network egress, for the most constrained environments. Not available, not being sold, and we are not offering a date. |
| Sovereign | In development | Not available, not being sold, and we are not offering a date. |
There is no multi-tenant or shared option, and one is not on a roadmap. Deployment models in full →
What we run, what you run.
Written down before anything is deployed. The layers in the figure at the top of this page, stated as obligations rather than as a diagram.
| Who | What they hold |
|---|---|
| Reign Ops | Operate the engine inside your authorization boundary. Enforce your identity provider at the edge. Automated patching on a cadence matched to upstream releases and scheduled through your change process. Monitoring, alerting, backup and a restore that has been exercised. Answer the pager, with a named engineer and a current runbook. |
| Customer | Your BPMN and DMN models, your decision tables and your REST integrations. Which processes are in scope and which are not. What a finding means and in what order it gets addressed. The approval on any change to the estate. |
| Reign Gateway, if taken | Identity, policy and a record on the model path for agent steps inside a process. Available today. Optional, priced separately, and absent by default. |
| Reign Assurance, if taken | The requirements those agent steps have to satisfy, turned into checks that run against the work, and the evidence a reviewer can follow. In co-design development, not shipping, and not sold. Nothing on this page depends on it. |
| The project | Fluxnova itself is maintained by the FINOS community under Apache 2.0. We operate a distribution of it; we do not own it, and nothing here makes the engine ours. |
Support scope and service levels are documented per engagement and available under non-disclosure rather than asserted here. Scope is agreed per engagement rather than assumed to be the whole estate.
The questions that arrive every time.
What is Fluxnova?
Is it actually maintained?
Are my Camunda 7 processes compatible?
What changed in 3.0?
We are staying on Camunda for now. Is that a conversation?
What is the support model?
Tell us where Camunda and Fluxnova run today.
Which edition or version you are on, roughly how many process definitions are in production, and what is forcing the question. We will come back with what the work actually involves, what we would take on first, and which part of the estate we would leave where it is.