Documentation / Deployment

Custom Domains

Give your Nexus instance a branded, per-tenant vanity hostname derived from your slug, backed by an automatically issued and auto-renewing managed TLS certificate at no extra cost — a commercial-cloud convenience that never puts Stingray in your data path.

A custom domain gives your Nexus instance a branded, memorable web address — a per-tenant hostname derived from your slug — secured by an automatically issued and auto-renewing managed TLS certificate. This page explains exactly what you get, how the binding works, how routing behaves, and the limits (notably that it is a commercial-cloud feature). It is for administrators and IT owners who want a clean, professional URL and need to understand the mechanics before enabling it.

What a custom domain gives you

Every Nexus instance is reachable by default at its Azure-assigned hostname. A custom domain adds a branded vanity host on top of that, at no additional cost:

A clean, branded URL your users recognize and bookmark, instead of a long machine-generated address.
A valid, auto-renewing managed TLS certificate issued and bound for you — nothing to buy, install, or remember to renew.
No extra cost. The managed certificate and the DNS record for your vanity host are included; there is no separate certificate authority bill and no per-domain fee.
A consistent browser sign-in experience. Browser-based sign-in to hosted Sites works on the branded host out of the box, because the host's sign-in callback is registered as part of binding it.

The custom domain is purely additive. Your instance's default Azure hostname keeps working exactly as before, so nothing breaks and there is no migration or cutover.

Your hostname is derived from your slug

Your vanity host is derived from the tenant slug you chose when you installed Nexus from the Azure Marketplace:

https://<your-slug>.stingraynexus.com

Slugs are unique per customer, so pick something short and recognizable — typically your company or team name. Because the slug is fixed at deploy time, so is the branded hostname it produces.

How routing works — and why your data still never transits Stingray

The vanity hostname resolves directly to your instance. There is no shared gateway, reverse proxy, or Stingray-operated front door sitting in front of your tenant — the branded host is a DNS name plus a certificate bound to your Container App. Because Nexus runs inside your own Azure subscription, your data never transits Stingray infrastructure, and enabling a custom domain does not change that. All the custom domain adds is a friendlier name in front of the same single-tenant instance described in the architecture overview.

Host handling and the default tenant

Nexus is deployed as a single-tenant instance, so it treats the incoming Host header permissively: the branded host, the default Azure host, and the health host all route to the same instance. Because the deployment is bound to one tenant (a DEFAULT_TENANT), the hostname does not need to select a tenant — it only needs to reach the instance. That is why adding or removing a vanity host is non-disruptive: the instance answers on every host that resolves to it, and the default hostname remains a fully working entry point at all times.

The two-phase setup

Custom domains are enabled in two phases. This ordering is deliberate, not an inconvenience:

Provision your instance. Nexus deploys into your Azure subscription and boots on its default hostname. You are fully operational on the default URL from the moment provisioning completes.
Bind the vanity host. Once the instance is running and has reported its address, three things are configured for your chosen hostname:

Step	What happens
DNS record	A record pointing your vanity host at your Nexus instance is published.
TLS certificate	A free, auto-renewing managed certificate is issued for the host and bound to your instance.
Sign-in callback	The branded host's SPA redirect URI is registered on the Entra app registration, so browser sign-in to Sites authenticates cleanly on the new origin.

The reason for two phases is a real dependency chain: the certificate can only be validated after the DNS record resolves, and the DNS record needs your instance's final address, which is known only after it first boots. Splitting the work lets each part complete reliably. Certificate issuance can take a few minutes (Azure allows up to about 20). Until phase two finishes you keep working normally on the default hostname — the vanity host simply turns on when it is ready.

Why the callback registration matters

Entra validates every browser sign-in against the redirect URIs on the app registration, and the branded host is a new origin to Entra. Binding the custom domain registers that origin's callback for you; without it, browser sign-in on the vanity host would fail with a redirect-URI error. This is the same per-host redirect-URI behavior described in Identity & Sign-In — the binding step just handles it on your behalf.

Self-healing by design

The binding step is idempotent and self-healing. If DNS is still propagating or a certificate is still validating, the process retries on its own schedule and finishes when everything is ready — no manual re-runs and no fragile one-shot steps. A host that is already fully set up is detected and left untouched, so re-running the binding is always safe.

Commercial cloud only

Per-tenant custom domains are a commercial-cloud convenience and are off for Azure Government / GCC-High deployments. Government instances run on their default hostname; the identity endpoints point at the Government authority (login.microsoftonline.us) as described in Identity & Sign-In, and branding via a managed vanity host is not part of the Government footprint. Everything else — sign-in, RBAC, connectors, pipelines — is identical; only the branded hostname is unavailable there.

Verifying the domain

After the vanity host is bound, confirm it is live by visiting the URL in a browser. A healthy instance:

Serves over HTTPS with a valid, trusted certificate (no browser warning).
Returns its health endpoint successfully at https://<your-slug>.stingraynexus.com/health.
Lets users sign in to hosted Sites directly in the browser on the branded host.

Removing a custom domain

A custom domain can be removed at any time. The vanity hostname and its certificate are taken down, and your instance continues to serve on its default Azure hostname with no interruption — because the default host was never disabled in the first place.

Summary

Custom domains give your Nexus instance a branded, professional URL backed by a free, automatically managed and auto-renewing TLS certificate, derived from your tenant slug. Setup is additive and self-healing, your default hostname keeps working throughout, the feature is available on commercial Azure (off in Government), and — because Nexus runs in your own subscription — your data never leaves your tenant.