Extra hostnames

A tunnel publishes one canonical hostname. An alias is an extra hostname that routes to the same tunnel, so the same service is reachable under more than one name without running a second tunnel.

Aliases are useful when:

• a platform expects a fixed hostname (an OAuth redirect, an integration URL);
• you want a friendly name alongside the one the tunnel was created with;
• the service moved to a custom zone but old links should keep working.

Every alias points at the tunnel’s canonical name. It is not a copy: there is one connection, one set of settings, and one traffic count.

Adding a hostname

Open the tunnel and use the Hostnames section on the Overview tab:

1. Type the label — the leftmost part of the name (home becomes home-<your-code>.hle.world).
2. Choose the domain: hle.world (the base domain) or one of your custom zones. You can only put an alias on a zone you belong to.
3. HLE validates the name as you type and shows the exact hostname that will be added. If it is taken or refused, the reason is shown in place.
4. Press Add. Remove a hostname with the Remove button beside it; the confirmation happens in the row, not in a browser dialog.

A hostname can only answer in one place. If it already belongs to a tunnel, another alias, a name reservation or a redirect, the add is refused and says so.

Base domain or your own zone

On the base domain an alias gets your user code appended, exactly as a tunnel name does, so aliases cannot collide between accounts. On a custom zone the zone’s naming mode decides the shape of member aliases; the zone owner may also alias the zone apex itself.

From your cluster or CLI

Aliases can also come from whatever creates the tunnel, through the generic options bag the CLI and the Kubernetes operator already carry:

• CLI — hle tunnel create jellyfin http://localhost:8096 --option aliases=jellyfin.example.com,media.example.com
• Kubernetes — the CRD spec.aliases field and the hle.world/aliases annotation are coming with the operator release.

The value is a comma-separated list of hostnames. Whitespace around an entry is ignored, names are lowercased, a trailing dot is dropped, duplicates collapse and empty entries disappear. Each hostname must be on hle.world or on a zone you may publish on, and is validated exactly like one you add in the dashboard.

A cluster declaration owns the aliases it declares: under strict sync the dashboard shows them read-only, while under initial sync the first declaration seeds them and you can change them afterwards. A CLI tunnel replaces its own options aliases on every registration. A hostname that is taken or refused is reported back — in the declaration’s status, or the client’s log — and never stops the tunnel coming up.

Limits

Aliases are available on Pay-as-you-go accounts:

Plan	Per tunnel	Per account
Pay-as-you-go	10	50

The Free plan does not include aliases. When a limit is reached, the server’s message names the limit and the plan; the form shows it verbatim.

Protection and access rules

An alias shares everything with the tunnel’s primary hostname: the email allow-list, IP rules, PIN, Basic Auth, the offline page and the webhook path all apply to every hostname that reaches the tunnel. Adding an alias never widens who can get in.

What the app sees

When forward_host is on for the tunnel, your local service receives the hostname the visitor used. A request to an alias arrives with that alias in the Host header, so an app that cares which name it was called by can tell the difference. With forward_host off, the service sees the tunnel’s upstream address instead, and the aliases are indistinguishable from the primary host.