configured
Trust · Deployment
Same container images, same code, three different places to run them
Moving between the three shapes below is a deployment decision, not a rewrite. Every one of them runs from the same images, built once and promoted, not rebuilt per environment.
The three shapes
What you operate, and what we operate, in each
| Shape | Who operates the cluster | Shared with other customers? | Where your data sits |
|---|---|---|---|
| Managed cloud | We do, on Microsoft Azure in the EU. | Possibly, each in its own identity realm and its own database. | In our infrastructure, in your own dedicated database. |
| Dedicated cluster | We do, on infrastructure reserved to your organisation. | No. The cluster itself is not shared with another customer. | In infrastructure that runs no other customer's workload. |
| Your own infrastructure | Your operations team, on your own Kubernetes cluster. | Irrelevant. It is your hardware. | Entirely inside your own chosen infrastructure and jurisdiction. |
For self-hosting, the documented, currently-run path uses MicroK8s, Canonical's lightweight Kubernetes distribution, on Ubuntu, with pinned-version upgrades rather than automatic ones, so your operations team controls exactly when the underlying platform changes. We ship the same container images plus the deployment manifests and the database migration scripts that accompany every release; running them is your team's responsibility, the way it is for any software you host yourselves. On-premises patches, updates and upgrade rights require an optional support contract; without one, your perpetual licence remains valid for the version you hold.
Multi-tenancy
One identity realm and one database per tenant
Each customer organisation gets its own realm in the identity server and its own separate database. A tenant's data physically resides in its own database rather than sharing one table with everyone else behind a tenant-id column, so a query cannot cross tenant boundaries by accident, because there is no shared row it could accidentally return. A small, separate registry database holds only which tenants exist and their connection settings, never any tenant's business data. Which identity realm and which database a request belongs to is derived from the login token itself, not from a header a client could set.
A dedicated cluster is a straightforward variant of this same model, not a different architecture: the realm-per-tenant, database-per-tenant design is what makes reserving a whole cluster to one customer a configuration choice rather than a separate product to build.
verified
How a release reaches you
Built once, promoted, not rebuilt per environment
Infrastructure and application state are declared in configuration held in version control and continuously reconciled against what is actually running, so what is deployed can always be compared against what was intended. A release candidate's container images are built once; moving that candidate toward production only re-tags the same images, it does not rebuild them, so what eventually reaches a live environment is byte-identical to what was validated earlier in the pipeline. Two independent, named approvals, one confirming the release works, a separate one confirming it is the right behaviour for the business, both have to pass before a release is cut.
Every database schema change ships as a paired upgrade script and its own rollback script, pinned to the release that introduces it. The migration runs automatically as part of the deployment, on the shared configuration database and on every tenant's own database, rather than as a manual step someone has to remember.
Backups and replication
What actually happens when something fails
The primary datastore runs as a multi-node replica set, with replicas placed so that no two of them ever land on the same physical node. The identity server's own database runs as a separately replicated cluster with automatic primary election: if the current primary node fails, the replication manager detects the outage, promotes a new primary, and the connection layer in front of the database routes new connections to it automatically. The former primary rejoins as a standby once it is back, without a person having to intervene for that specific handover to happen.
Backups run as scheduled jobs, per tenant, writing to storage outside the cluster itself so a cluster-level failure does not also take the backups with it. A new tenant's deployment is not signed off as complete until a backup has actually been downloaded, unzipped, and confirmed to contain real data, not just confirmed to have completed without error.
verified
Disconnected and air-gapped environments
What the architecture supports, stated carefully
The self-hosted path is built so that nothing in the core application, the database, the message queue, the cache, or the identity layer requires reaching the public internet at runtime. Container images are pulled from a registry that can be mirrored into a fully disconnected one.
That is a description of the architecture, not a claim about a completed deployment. We are not reporting that a fully air-gapped environment has been run in production; we are describing what the design supports. If your environment requires this, say so early: it changes registry mirroring and how updates reach you, and it is worth a specific conversation rather than a line on this page.
Service commitments
The standard SaaS commitment and other deployment arrangements
Read next
The rest of the trust section
Mechanism
Security
Authentication, the internal call gate, and encryption of stored documents.
Mechanism
Data protection
What personal data is held, the audit trail, and how residency follows the shape above.
Persona
The IT security desk
Eleven of the most common questions, one table, one straight answer each.
Bring us a month that went wrong.
A working session is 45 minutes with your own roster on screen, not a canned demo. Bring a pattern that fought you and we will walk through what the engine would have done with it.