Frequently Asked Questions
Why Does Arminius Exist?
Arminius is developed for the requirements of BundesMessenger and enterprise Matrix deployments: maintainable protocol code, integration with existing identity infrastructure, predictable operations, and explicit service boundaries. It also provides a foundation for integrating MLS and pseudonymous identities.
Why Build Another Matrix Homeserver in Rust?
An independent implementation gives the project control over its architecture and how new protocol capabilities fit into it. Rust’s ownership and type system help prevent classes of memory and concurrency errors, while traits support clear boundaries between protocol logic and infrastructure.
The value of Arminius depends on how well it meets these requirements. Compatibility, performance, and operational reliability must be demonstrated through tests and deployment experience. Relation to other great existing Homeservers:
- Conduit and Continuwuity - great for small appliances, hard to scale for HA setups
- Tuwunel - even greater for small appliances, hard to scale for HA setups
- Dendrite - cool thing, architecture was mostly the blueprint for Arminius
Can I Run Arminius Locally with Reasonable Effort?
We provide also a docker-compose setup but the most supported local deployment is based on Nix derivations. Yes, being new to Nix makes this hard and somehow alien but it’s really worth the effort and let’s you run full setup with only a few commands and also makes it possible to do most of the CI Pipeline locally in a reproducible way. Oh, did we mention that Nix makes everything reproducible? See this for running it with Nix
Is Arminius Ready for Production?
Arminius is under active development and also the necessary Helmchart for cloud-native Provisioning and Operation of Arminius is under active Development. We’re planning for the first productive release in Summer 2027.
Is Arminius Feature-Complete?
Complete Matrix specification coverage is not claimed. The current blacklist of Complement Tests gives a good pointer about the already supported features:
- https://gitlab.com/bundesmessenger/backend/neo/arminius/arminius/-/tree/main/nix/packages/complement_utils
Is It Possible to Migrate from Other Homeservers to Arminius
While most homeserver implementations doesn’t plan or cover migration from other homeserver implementations, we will provide this functionality. We also attempt to provide a standardized migration format that could be used for generic migrations between Homeservers. See this ADR for more information: Homeserver Migration
Can I Use Existing Matrix Clients, Bridges, and Bots?
We are targeting especially compatibility with existing Matrix Clients. Our priority for client compatibility are right now Element-derived Client-Apps like the BundesMessenger.
The Arminius Application Service engine will be called Extension API and will strictly following the existing Matrix Spec Application Service API. Like with Synapse an Extension can be created in any programming language, as long it uses the correct API Specs. Therefore existing Application Services should also work with Arminius.
How Is Compatibility Tested?
Arminius exercises protocol behavior with the Matrix Complement test suite. Additionally we’re doing a extensive set of own E2E Tests using the Matrix-Rust-SDK (also with Federation between different Homeservers (Arminius and Synapse). See the tests section in the docs for more detailed information about the tests and how to run them.
Which Infrastructure Does Arminius Use and Will It Support Kubernetes?
Additional Components
The current design uses PostgreSQL for persistent data and NATS JetStream for internal messaging. The architecture guide describes service boundaries of each component.
Cloud-Native Design (Kubernetes)
The Arminius components are developed for an cloud-native Kubernetes environment with a Helm Chart. We will provide all necessary configuration and components for running Arminius in a Kubernetes Cluster. Albeit we won’t provide productive deployments for the additional components NATS and PostgreSQL. The included provisioning for these components will only cover testing purposes.
What Means Support of Enterprise Authentication?
The architecture aims to keep authentication separate from Matrix protocol processing and message storage, allowing integration with enterprise identity infrastructure. Consult the configuration guide for the supported authentication service, client configuration, and provisioning requirements. This is still work in progress
Can I Migrate from Another Homeserver?
Use only an explicitly documented migration path in the migration guide. Matrix protocol compatibility does not imply database compatibility. Reusing another homeserver’s database requires a migration procedure that covers its schema and data.
Where Are Upgrades, Backups, and Monitoring Documented?
The documentation for this is still work-in-progress. We already provide documentation for the incorporation and usage of OpenTelemetry Traces:
Is Arminius Certified for Handling Classified Information?
No. Arminius is regarded now as an ordinary Matrix Homeserver that is capable of providing the same security clearance as other Homeserver Implementations. We are targeting with specific MLS-driven Client-SDK and server-side components for a certification for VS-NfD.