Choosing Your Mandraki Deployment Model

For most software, “where it runs” is a one-line answer in the procurement document. For collaboration tools used by organisations under regulatory pressure — defence suppliers, regional administrations, ministries, healthcare networks — it is the question that decides whether the tool can be adopted at all.

Mandraki ships in four deployment models. Same product, same protocols, same security model — different operational boundary. This post explains what each model means in practice and how to pick the one that fits.

Why deployment isolation is a separate question from data residency

It is tempting to collapse the question into “is my data in the EU.” Data residency matters, but it is not the same as deployment isolation. A shared multi-tenant SaaS hosted in Frankfurt still co-resides your data, your keys, and your audit logs with everyone else’s on the same physical infrastructure. For many organisations that is acceptable; for some — particularly those whose data classification or accreditation framework explicitly forbids shared infrastructure — it is not.

Deployment isolation answers a different procurement question: how much of the operational substrate is shared with other customers, and who has access to it. The four Mandraki deployment models trade off operational complexity against isolation, and the right answer depends on which side of that trade-off your accreditation framework lives.

The four models

1. Shared multi-tenant SaaS

Our hosted offering on app.mandraki.cloud. Application code, databases, object storage, and SFU media routing are shared across organisations, with logical isolation at the organisation level (every row in every table is scoped to an organisation ID, and access guards enforce it on every request). Keys, audit logs, and recordings are encrypted with per-organisation key hierarchies — never co-mingled in plaintext — but they sit in shared infrastructure.

Choose this when: your data classification does not require physical isolation, you want zero operational overhead, and you are comfortable with logical separation backed by encryption and access guards. This is how most commercial customers and many smaller public-sector teams run.

2. Dedicated single-tenant instance

We deploy a complete Mandraki stack — API, frontend, SFU, data tier, management console — into infrastructure reserved for your organisation. No other tenant shares the application servers, the database, the object storage, or the encryption key hierarchy. We operate it; you sign the data processing agreement; everything still runs on EU hyperscale infrastructure.

Choose this when: your accreditation framework explicitly requires single-tenant infrastructure, you want a dedicated audit boundary, or you anticipate per-tenant performance characteristics (e.g., a national administration with a large user base) that justify the operational cost. Common for defence suppliers and central-government deployments.

3. Your own cloud account

We deploy Mandraki into infrastructure that you control. You hold the cloud account; we install, configure, and operate the platform within it. Your security team retains the ultimate operational lever — you can audit our access, restrict network egress, and apply your existing cloud-account controls (perimeter logging, IAM, key escrow) without us being in the way.

Choose this when: your organisation has a cloud sovereignty programme that requires all production workloads to land in accounts under your direct contractual control with the cloud provider — common for ministries with an established sovereign-cloud framework, or for organisations subject to operational doctrine that treats cloud-account ownership as the trust boundary.

4. On-premises

The Mandraki stack runs inside your own data centres or private cloud, behind your firewall. The product is the same; only the substrate changes. Updates ship as signed releases; we provide operational support, runbooks, and an upgrade cadence; your operations team owns the box.

Choose this when: your environment is air-gapped, your classification framework forbids any external cloud presence, or your operational doctrine requires that the entire stack — code, data, keys, telemetry — live within your physical perimeter. Common in defence, intelligence-adjacent work, and certain critical-infrastructure operators.

How to pick

In practice, the answer comes from three questions:

1. What does your accreditation framework or data classification require? If the framework names “single-tenant” or “dedicated” as a requirement, the choice is already made. If it speaks in terms of “data residency” only, shared SaaS is usually sufficient.

2. Where does your security team draw the trust boundary? Some treat the cloud account as the boundary (then “your cloud” is the right model); some treat the physical perimeter as the boundary (then on-prem is the right model); some are comfortable with logical-plus-cryptographic boundaries on shared infrastructure (then SaaS is fine).

3. What operational overhead can you absorb? Shared SaaS is zero. Dedicated single-tenant is small — we operate it. Your cloud is moderate — you and us share the operational map. On-prem is significant and requires an internal team to run the platform alongside everything else.

You do not have to commit to a model on day one. Many customers start on shared SaaS for a pilot, then graduate to dedicated or your-cloud as the deployment hardens into a regulated production system. The data model is portable across deployments; the migration is engineered, not handwaved.

What stays the same across all four

The product is identical. The end-to-end encryption posture is identical. The protocol choices — MLS for messaging, SFrame for media, WebRTC over mediasoup, three-layer envelope encryption with optional BYOK — are identical. The audit logging, the access guards, the policy engine, the data export endpoints: identical.

What changes is the operational boundary, who has hands on the infrastructure, and where the data physically lives. That is exactly the surface that procurement, accreditation, and operational doctrine care about — and exactly the surface where most collaboration vendors have nothing to offer beyond a shared SaaS console.

If your organisation is evaluating Mandraki and needs help choosing the right deployment model, we are happy to walk through it with your security and procurement teams. The right answer is rarely obvious from the marketing material; it usually emerges from a half-day conversation about your constraints.