Access URLs

Every Novantra organization is reached through one or two URLs:

• A workspace URL for people on your team, and
• A public URL for external participants who interact with your organization without a Novantra account (for example, when you send someone a link to fill in a form).

Both URLs always point at the same organization, but they are kept on separate hostnames so internal and external traffic stay clearly distinct.

How those URLs are chosen, who controls them, and whether you can use your own depends on how you run Novantra: hosted by us (Cloud), or installed on your own infrastructure (Sovereign).

The two surfaces

Whichever deployment you use, the two URLs play the same roles:

If you do not configure a separate public URL, the workspace URL is used for both. Most organizations configure both.

Cloud (hosted by Novantra)

In Cloud, Novantra manages the default hostnames and certificates for you. You pick a region or cell first, then pick a short name for your workspace inside that cell.

How your URLs are chosen

When you create your Cloud workspace, you choose a cell and a subdomain. The cell determines the regional apex domain; the subdomain becomes the prefix on both surfaces:

• Workspace URL: https://<your-name>.cloud.<cell>.novantra.io
• Public URL: https://<your-name>.public.cloud.<cell>.novantra.io

For example, if you choose acme in the UAE cell, your team signs in at acme.cloud.ae.novantra.io, and external participants land on acme.public.cloud.ae.novantra.io. If you also create an EU workspace called acme, that workspace uses the EU cell URL instead.

Rules for the subdomain

• Lowercase letters, numbers, and hyphens only.
• Must start and end with a letter or number.
• Between 1 and 63 characters.
• Cannot match a reserved name (such as admin, api, app, auth, control, docs, health, help, status, support, system, www).
• Must be available inside the selected cell.

The workspace creation form checks availability for the selected cell.

Certificates

Novantra holds and renews certificates for the regional Novantra-hosted domains. You don’t manage anything TLS-related yourself for those defaults.

Custom domains

Custom domains are managed separately from the default Novantra-hosted URL where that capability is enabled. The default regional URLs stay available; custom domains add customer-owned aliases for the same organization and selected surface.

You can configure two independent custom-domain surfaces:

• Workspace custom domain - for signed-in member/admin workspace traffic.
• Public custom domain - for external participant/public-access traffic.

Novantra does not impose the label. You can choose names such as app.example.com, training.example.com, ae.novantra.example.com, or another subdomain you own. Use a subdomain you own for the custom domain.

For managed Cloud, point your customer DNS to the cell-specific target shown in the Domains settings page:

For example, a UAE workspace domain might be:

app.example.com CNAME workspace.cloud.ae.customers.novantra.io

And a UAE public-access domain might be:

training.example.com CNAME public.cloud.ae.customers.novantra.io

After you add the DNS record, return to Settings -> Domains and run verification. Activation requires DNS and certificate readiness before traffic is accepted on the custom hostname.

Sovereign (self-installed, on-prem)

In Sovereign, you choose everything. Novantra never sees your URLs, and you decide whether they live on a public DNS name, a private corporate name, or an IP address.

URLs are set in two places

There are two layers of URL configuration in Sovereign, and they serve different purposes:

1. The install-level admin URL

Set once during installation, in the setup wizard. This is how install administrators reach the system console (the screen where you create organizations, manage licensing, view installation health, and so on). It is a single base URL for the whole install, for example https://manage.novantra.acme.internal.

You can change it later, but doing so means updating DNS, your reverse proxy, and your TLS termination at the same time. Plan it as an infrastructure change, not a settings change.

2. Per-organization access URLs

Set per organization, after the organization is created, from the system administration console. This is where the workspace URL and public URL described above are actually defined.

For each organization you can configure:

• Member URL - workspace URL for that organization’s team.
• Public URL - public-access URL for external participants. If you don’t set this, public traffic falls back to the member URL.

If you set neither, the system derives a fallback URL from the install base URL using a path-based pattern. Most operators configure them explicitly so each organization has a clean, recognizable URL.

Every change is recorded with an audit reason. The form asks “Why are you changing this?” before saving.

URL rules

Whatever you put in these fields must be a complete, valid URL:

• http:// or https:// only.
• A real hostname or IP address, with an optional port.
• An optional path prefix (for example, https://app.acme.com/novantra).
• No usernames or passwords embedded in the URL.
• No query string or fragment.

The console rejects values that don’t match these rules with a clear error before saving.

Certificates and TLS

You have two options:

Recommended: terminate TLS at a reverse proxy. Run Novantra plain-http behind nginx, HAProxy, an ingress controller, or any other proxy you already use. Your existing process for issuing and renewing certificates keeps working unchanged. This is the path we recommend for almost everyone because it keeps cert lifecycle outside the app.

Alternative: let the application terminate TLS. Supply a certificate and key path to the install. The application will serve TLS directly. This is simpler for very small deployments but means your cert renewal process now has to know about Novantra.

Changing URLs later

Changes are allowed. The workflow looks like this:

1. Update DNS to point the new hostname at your install.
2. Update your reverse proxy or TLS config so the new hostname is served.
3. In the system console, edit the organization’s member URL and/or public URL.
4. Provide an audit reason for the change.

There is no automatic redirect from the old URL to the new one. If users still have bookmarks against the old hostname and you want those to keep working, leave the old DNS pointing at your install and let your reverse proxy redirect to the new one.

Why the workspace and public URLs are separate

People often ask “why two URLs instead of one?” The split exists because the two audiences need very different treatment:

• The workspace URL is for people who have accounts. They sign in, they have permissions, they can see internal admin features. Cookies, sessions, and security headers are scoped to this hostname.
• The public URL is for people without accounts who are interacting with one specific surface (a form, a request, a link). Their session is short-lived, scoped to that one interaction, and isolated from anything internal.

Keeping them on separate hostnames means a cookie or session from one surface can never accidentally be sent to the other, even if a link is shared in the wrong direction.

If you only ever use the workspace surface, you can leave the public URL unset (Sovereign) or simply never publish the public-side hostname (Cloud) and nothing breaks.

At a glance

Related

• Cloud Regions & Residency
• Self Managed Storage
• Self Managed Secret Keys