Skip to content

SSL and Domains Updated 2026-05-27

Domain name management

Index of domain-related capabilities on the Stack Harbor PaaS — custom domains, domain swaps between environments, multiple domains on one environment, and internationalized / generic TLD support.

This page is the index for everything domain-related on the Stack Harbor PaaS — attaching domains you own to environments, swapping domains between environments for blue/green or staging-to-production cutovers, hosting multiple domains on a single environment, and using internationalized or generic top-level names.

The platform treats domains as first-class environment attributes. Adding, removing, or swapping a domain is a dashboard or API action and takes effect immediately — DNS propagation aside.

In this section

Custom domains

Custom domains covers the basic flow: buy a domain at a registrar, create a DNS record (CNAME, ANAME, or A) pointing at your environment, and — if you don’t have a public IP attached — bind the domain in the dashboard so the shared load balancer routes traffic correctly.

This is the right starting point for any environment that needs to be reachable on a domain you control rather than the platform-issued URL.

Domain swap

The platform’s domain swap action moves the domain attachment between two environments atomically. It is the standard pattern for blue/green deployments and for promoting a staging environment to production without changing DNS:

  1. Run the new version in a separate environment with the same custom domain you eventually want it to serve.
  2. Verify on the staging URL.
  3. Swap — production keeps serving on the same domain, but now from the new environment. The old environment is still online (now reachable on the staging URL) so you can roll back instantly.

Swap works with public IPs (DNS unchanged, IP reassigned) and with shared-load-balancer environments (domain binding moved between environments).

Multiple domains on one environment

Multiple domains covers serving more than one domain from a single environment. The most common reason is hosting several apps on one Tomcat, GlassFish, or PHP server — separate virtual hosts, separate document roots, one set of compute resources.

The pattern is the same across application servers:

  1. Bind the additional domain to the environment (via DNS plus dashboard binding).
  2. Add a virtual-host block in the application server’s configuration that routes the new domain to its own document root or context.
  3. Restart or reload the application server.

gTLD and IDN domains

gTLD and IDN domain support covers two specific cases:

  • Internationalized domain names (IDN) — domains in non-Latin scripts (Cyrillic, Chinese, Greek, etc.) using Punycode under the hood. The platform accepts them in environment names, aliases, and custom-domain bindings.
  • Generic top-level domains (gTLD) — TLDs beyond the original .com, .org, .net set — .academy, .best, .cloud, etc. They behave like any other TLD on the platform.

Container DNS hostnames

Inside an environment, the platform exposes container DNS hostnames so containers can address each other by name without hard-coding IPs. This is documented separately under the Networking section.

See also