DNS hostnames for direct connection to containers

Every container on the Stack Harbor PaaS receives a set of DNS hostnames at creation time. They point to the container’s internal IP, the external IP (when one is attached), or both. Knowing which hostname to use makes inter-tier connections, internal tooling, and migration between regions much simpler — application code does not need to learn IP addresses, only stable names.

This page describes the hostname formats the platform registers automatically.

Hostnames for specific containers

Every container is addressable through two equivalent fully-qualified names:

• node${nodeId}-${envName}.${platformDomain}
• node${nodeId}.${envName}.${platformDomain}

The placeholders are:

• ${nodeId} — an integer identifier assigned by the platform at container creation. Stable for the life of the container.
• ${envName} — the environment name (not the display alias) chosen at environment creation.
• ${platformDomain} — the domain name of the Stack Harbor PaaS region.

Both forms resolve from inside the platform and from the public internet — they can be used for internal connections and for external SSH or HTTP access, with the usual public-IP and firewall considerations.

Stack-specific hostname prefixes

A handful of platform-managed stacks also expose a hostname keyed on the stack name instead of the generic node prefix. These extra names work only under platform domains that use a hyphen as the separator (the dash form, not the dot form).

These names are equivalent to the generic node${nodeId}-… form — they’re a convenience for human readability.

Hostnames for a whole layer

To resolve every container in a single layer at once (useful for scripts that want to iterate over an application tier):

• ${nodeGroup}.${envName}.${platformDomain}

${nodeGroup} is the layer identifier. Default layers carry well-known names — bl (balancer), cp (compute / application server), sqldb (SQL database), nosqldb (NoSQL database), cache, vds, storage, build. Extra layers added through the topology wizard get indexed names — cp2, cp3, …, extra, extra2, ….

The hostname resolves to all internal IPs in the layer. The platform updates the DNS record automatically when containers are added or removed.

Short hostnames inside one environment

From inside a container, you can drop the environment and platform-domain suffixes and address peers by short name:

• node${nodeId} — one specific container.
• ${nodeGroup} — a whole layer.

These short names resolve only within the same environment. They make application configuration files portable across regions — a container moved to a new region picks up its new platform domain transparently because the short names do not encode it.

Hostnames for linked layers

When two layers are joined with a container link, the platform registers additional DNS entries that are scoped to the linked pair. For a link with alias ${linkAlias}:

• ${linkAlias}_${N} — addresses a specific container in the target layer. The master container is always _1; remaining containers are sorted by nodeID ascending and assigned _2, _3, ….
• ${linkAlias} — round-robins across all containers in the target layer.

The indexed form (${linkAlias}_N) resolves only internally — between the linked source and target layers. The bare alias also resolves only between the linked layers. Appending the environment domain — ${linkAlias}.${envName}.${platformDomain} — produces a name that resolves externally as well, exposing the target layer to the internet (subject to public-IP and firewall configuration).

Worked example

A target layer contains three containers with nodeID 123, 124, and 125, where 124 is the master. After a link with alias app:

• app_1 → container 124 (the master).
• app_2 → container 123 (lowest remaining nodeID).
• app_3 → container 125.
• app (no index) → round-robin across all three.

See also

• Container links
• Connect to your custom container
• Custom container SSH access