Skip to content

DevOps portal — Hostnames and domains

An app's route can only use a hostname its namespace allows. You set the namespace's hostnames when you request it, or later with Edit hostnames in the namespace's drawer; then each app picks one.

Namespace hostnames

Each hostname is a name under one of the zones the form offers for the namespace's environment:

Zone Example Reachable
Internal (k8s-colo-1.infra.jsm) orders.k8s-colo-1.infra.jsm Inside the network and over the VPN
Public (k8s-colo-1.jsm.systems) orders.k8s-colo-1.jsm.systems The internet, through the web firewall
Shared domains your team may use orders.pubinvest.co.uk The internet, through the web firewall
  • Under the internal and public cluster zones a hostname is one label: orders.k8s-colo-1.infra.jsm, not api.orders.k8s-colo-1.infra.jsm.
  • A hostname listed by one namespace can't be listed by another, on any cluster.
  • Names the platform uses itself (devops.pubinvest.co.uk, id.pubinvest.co.uk, …) are refused.

Tenant domains

Shared public domains (tenant domains) are offered only to teams that platform has enabled them for. Ask platform to enable one for your team; once it's on, it appears in the hostname picker.

How deep you can go depends on the domain:

Domain Names allowed Shared
pubinvest.co.uk Any depth: xyz.pubinvest.co.uk, api.xyz.pubinvest.co.uk. Never pubinvest.co.uk itself. Platform names and everything under them are refused (devops.pubinvest.co.uk, a.devops.pubinvest.co.uk) Any number of teams; each exact name belongs to one namespace
jsm.systems, hey-liverpool.co.uk One label: shop.hey-liverpool.co.uk, not a.shop.hey-liverpool.co.uk and not the domain itself Any number of teams
Every other domain offered (the venue and brand domains, such as einsteinbierhaus.co.uk) The whole zone: the domain itself and names at any depth under it One team owns the whole zone

The picker labels them public, shared, public, shared, any depth and public, whole zone. For a whole zone, leave the name empty to use the domain itself (einsteinbierhaus.co.uk).

Names on a tenant domain are public only: an app on one must be Public, through the web firewall, not internal or both. Callers inside the network reach it through the web firewall like anyone else.

Adding a name on a tenant domain needs platform approval, even in dev, because it exposes a service to the internet. Removing one doesn't.

Any name: wildcards

Instead of listing every name, tick Any name on a shared-domain row. The namespace then lists *.pubinvest.co.uk (for example), and each app picks its own name under it: in the app form, choose Any name under pubinvest.co.uk and type the name (shop, or api.shop where the domain allows any depth).

  • The depth follows the domain: one label for jsm.systems and hey-liverpool.co.uk, any depth for pubinvest.co.uk and whole zones. A wildcard never covers the domain itself: a whole zone's apex needs its own entry.
  • Any number of namespaces, in any team, may list the same wildcard.
  • A name another namespace lists explicitly is theirs: your wildcard doesn't cover it, and the app is refused.
  • One app per hostname, across every namespace and cluster, whether the name is listed or covered by a wildcard.

Adding a wildcard needs platform approval, like a single name on a tenant domain.

DNS and certificates

You don't request either.

  • Internal names resolve inside the network once the route exists.
  • Public names are published automatically once the web firewall serves the app: the public DNS record appears a few minutes after the merge, and the web firewall's certificate follows on its next run. Until then the name doesn't resolve, or shows a certificate error for a short while.

Removing the route (making the app internal, or deleting it) removes the public record.