Cloud Regions & Residency
Novantra Cloud uses regional cells for managed-cloud residency. A cell is a deployed Novantra Cloud environment in a specific residency boundary. It has its own workspace runtime, public-access runtime, regional platform database, tenant databases, storage, jobs, backup posture, and operational evidence.
When you create a workspace from the customer portal, you choose the cell first. The workspace is then provisioned inside that selected cell.
Creating a workspace
Workspace creation happens from the customer portal:
- Open Workspaces in the customer portal.
- Select the target region or cell.
- Choose the workspace name and default Novantra subdomain for that region.
- Choose whether to start with Novantra-managed storage or customer-managed storage setup.
- Create the workspace.
- Open the regional workspace URL when provisioning completes.
The portal coordinates the request, but the selected regional cell performs the actual provisioning. If a cell is unavailable, in maintenance, or suspended, it will not be offered for new workspace creation.
Workspace provisioning is retry-safe. The portal creates a provisioning operation before it asks the selected cell to create the workspace. If a browser, network, or regional API retry happens after the regional cell already succeeded, Novantra resolves the existing operation instead of creating a duplicate workspace.
If provisioning fails before a usable workspace exists, Novantra cancels and cleans the incomplete reservation where safe, then releases the regional subdomain for retry. If the system cannot prove whether regional resources were created or cleaned, the workspace locator stays in a blocked support state until Novantra resolves it from the selected cell context.
Default URLs
Novantra-hosted workspace subdomains are region-local. The same short name can be used in different cells when policy allows it, because each cell has its own apex domain.
Examples:
| Cell | Workspace URL |
|---|---|
| UAE | https://acme.cloud.ae.novantra.io |
| EU | https://acme.cloud.eu.novantra.io |
| KSA | https://acme.cloud.sa.novantra.io |
Custom domains are configured separately from the default Novantra subdomain. A .com domain is not blocked just because the workspace is in the UAE, and a .ae domain is not proof that data stays in the UAE. Domain names are identity and routing signals; residency is based on where the runtime and material data stores live.
What the global portal stores
The customer portal is a global account shell. It stores account and coordination data needed to show your workspace directory and let you enter the correct regional workspace.
By default, the global portal can show:
- workspace name;
- selected region or cell;
- workspace URL;
- lifecycle and provisioning status;
- plan or license summary;
- last health summary;
- backup, storage, key, domain, and email posture summaries.
The global portal does not pull governed workspace records into a global dashboard. Evidence, assessments, findings, incidents, audit package sources, documents, audit rows, and other work data stay in the regional workspace. To work with that data, open the owning workspace in its region.
Cross-region workspace lists are supported in the global portal, but governed work data stays in its regional workspace and is not aggregated across regions.
What stays regional
For a country-resident workspace claim, every material runtime surface needs to align with the selected cell and policy:
- workspace app runtime;
- public-access runtime;
- tenant database;
- regional platform records for that workspace;
- object storage and customer-managed storage bindings;
- key provider access path;
- backup artifacts and restore validation;
- regional jobs and queues;
- logs and operational telemetry;
- support artifacts when strict support residency is enabled;
- mail providers, AI providers, and other external processors where they receive sensitive content.
Novantra will not claim that a workspace is country-resident based on the selected URL alone.
Support data
Account, billing, and license support remains global because it belongs to the customer relationship rather than a specific workspace.
Workspace-specific support should carry the selected cell and workspace context. In strict regional cases, support bodies and attachments may need regional routing or a customer-approved exception. Avoid placing regulated evidence, screenshots, raw logs, or customer data in a global support ticket unless your policy allows that support path.
Custody options and residency
These options compose with the selected cell in different ways:
| Option | Residency meaning |
|---|---|
| Custom domain | Advisory. It can support public identity requirements, but it does not prove data residency. |
| Bring Your Own Email | Risk-bearing. Email can expose recipient metadata and may expose content if templates include sensitive details. Strict policies may require aligned provider region or an approved exception. |
| Self Managed Storage | Residency-bearing. Files and generated artifacts live in the bucket you choose. Strict policies may block misaligned storage regions. |
| Self Managed Secret Keys | Custody control. Key provider region and access path can affect residency evidence depending on the selected policy. |
| Backup targets | Residency-bearing. Backup artifacts must follow the same residency posture as the workspace when strict residency is required. |
Sovereign installations
Novantra Sovereign uses a different model. One self-managed installation is one residency boundary. If a customer needs an EU sovereign environment and a UAE sovereign environment, they should run two licensed installations, one in each country or residency boundary.
A Sovereign admin can create multiple organizations inside the same install, but those organizations inherit that install’s operational boundary.