Two models are available. Two are in development. One will not exist.
Reign runs as a single-tenant dedicated instance, in our environment or in the customer’s own cloud account on AWS or Azure. Both are available today and both are single-tenant. Air-gapped and sovereign are in development. This page states which is which.
If a deployment model is not listed as available below, treat it as not available.
A single-tenant dedicated instance, in our environment or in yours.
| Model | Status | What it is |
|---|---|---|
| Single-tenant dedicated instance | Available today | The instance is provisioned for one customer and serves that customer only. |
| Customer cloud | Available today | Deployment into the customer’s own cloud account on AWS or Azure. Google Cloud is planned for 2027. The instance is still provisioned for one customer and serves that customer only. |
| Air-gapped | In development | Air-gapped deployment. Not available today, and not being sold. |
| Sovereign | In development | Sovereign deployment. Not available today, and not being sold. |
| Multi-tenant or shared SaaS | Not on offer | There is no multi-tenant option and no shared SaaS edition. Those models are not on a roadmap. |
What single-tenant means in concrete terms.
Nothing is shared with another customer’s instance. There is no pooled application tier, no pooled database and no shared workload plane between customers.
What is not on offer.
What stays inside your boundary, and what does not.
The shape of the boundary is below. The exact contents are written down for each deployment and agreed before anything runs.
Inside the customer boundary
- Source code, repositories and branches held in the instance.
- Build artifacts and pipeline output produced in the instance.
- The evidence and records generated by work in the instance.
- Identity and access configuration for the instance.
- Configuration and policy set for the instance.
Outside the customer boundary
- Where the instance runs in infrastructure iTmethods operates, that infrastructure is ours. Where it runs in the customer’s own cloud account, the account is theirs and the billing relationship with the cloud provider is theirs. Which of the two applies is written into the deployment record.
- Operational telemetry required to keep the instance running is handled by our operations team. What that telemetry contains is listed for each deployment.
- Named operations staff hold administrative access in order to run the platform. Who they are is recorded, and access is reviewed.
- Platform releases originate with us, not with the customer, and are applied under the change process below.
If an item matters to a regulator or an internal control, it is written into the deployment record for that instance rather than left to a general statement on a website.
How a change to the deployment is proposed, agreed and recorded.
Four steps. No verbal changes, and no changes applied because they seemed obvious at the time.
Proposed
A change is raised in writing as a merge request in the GitLab instance we operate. It states what is changing, why, what it touches, and how it would be reversed.
Reviewed
Named owners on both sides review it. The customer has a named owner and so do we. A change that alters the boundary, access or evidence handling is flagged as such at this point rather than later.
Agreed
The change is applied after both named owners approve it. Emergency work follows the same path, with the approval recorded as soon as the situation allows and never quietly skipped.
Recorded
The merge request is the record. It carries the date, the approvers, the reasoning and the state before and after. A reviewer can read the sequence of changes to an instance without asking us to reconstruct it.
Ask about the model, not the roadmap.
We can walk you through the single-tenant instance in detail, including the parts that sit outside your boundary. If your requirement is air-gapped or sovereign, say so early and we will tell you plainly where that work stands.