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 hostnames and certificates for you. You pick a short name for your organization at signup, and that becomes the prefix on both URLs.

How your URLs are chosen

When you create your Cloud organization, you pick a subdomain. That subdomain is used to build both surfaces:

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

For example, if you choose acme, your team signs in at acme.cloud.novantra.io, and external participants land on acme.public.cloud.novantra.io.

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 - one organization per subdomain.

The signup form checks availability for you as you type.

Certificates

Novantra holds and renews the certificates for *.cloud.novantra.io and *.public.cloud.novantra.io. You don’t manage anything TLS-related yourself.

What’s not in Cloud yet

Custom domains (for example, app.acme.com pointing at your workspace) are not supported in Cloud v1. If you need your team to reach Novantra under your own corporate domain, see the Sovereign section below, or talk to support about your timeline.

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

• Self Managed Storage
• Self Managed Secret Keys