A custom container on the Stack Harbor PaaS is reachable from two directions: from other containers inside the platform (an internal connection) and from the public internet (an external connection). Each direction has a few different mechanisms with different trade-offs. This page lays them out so you can pick the right one.
Internal connections
Every container gets an internal IP and a set of internal DNS names at creation. Containers in the same environment — and containers in linked environments — can reach each other through that internal network.
Through a container link
The recommended way to wire two layers of one environment together. Define a link on the consumer layer, alias the target layer, and the source containers receive the target’s connection-relevant environment variables plus a DNS alias for the target.
Benefits: no ports exposed externally, configuration travels with the topology, environment-variable changes propagate automatically.
By internal DNS name
If a link is more machinery than you need — you already know the target’s hostname and want to reach it from application code or config — the platform’s internal DNS resolves directly:
node${nodeId}-${envName}.${platformDomain}for a specific container.${nodeGroup}.${envName}.${platformDomain}for a whole layer.- Short forms (
node${nodeId},${nodeGroup}) work inside the same environment.
The naming conventions are documented in DNS hostnames for direct connection to containers.
By internal IP
The internal IP of any container is visible in the dashboard — expand Additionally on the container row. The IP is stable for the life of the container, but a redeploy or migration can change it, so internal IPs are best treated as a fallback for tooling that can’t resolve DNS.
The same information is mirrored in the container-creation email sent to the account owner: Access URL is the internal DNS name, IP is the internal address.
External connections
Three mechanisms, ordered from least to most operational overhead.
1. Open in Browser through the shared load balancer
If the container exposes an HTTP service on port 80, the platform’s shared load balancer routes traffic to it automatically using the environment’s default domain. Click Open in Browser next to the container or the environment, and the browser opens that domain in a new tab.
For containers without a public IP listening on a custom TCP port, the platform also runs automatic port redirection: incoming requests on the default domain are forwarded to a detected listener port inside the container. This makes most ad-hoc deployments reachable as soon as they’re up.
If you want to disable the redirect, configure the container’s firewall rules to block it.
2. Endpoints (port mapping through the shared load balancer)
For more deliberate exposure — a non-HTTP service, a custom TCP port, a port that the auto-redirect can’t reach — use the Endpoints feature in the environment’s Settings.
An endpoint maps a private port on a chosen container to a randomly assigned public port on the shared load balancer. The dashboard surfaces the resulting Access URL with the port; that URL is then reachable from the public internet.
Endpoints are useful when you want to expose a specific port without burning a public IP, and when you can live with the platform-assigned port number.
3. Public IP
Attaching a public IP gives the container its own routable address. The container can then listen on any port — no shared-load-balancer mapping, no auto-redirect, no port-translation surprises.
A public IP also unlocks features the shared paths don’t have:
- Custom SSL with your own certificate.
- Unlimited concurrent connections — the shared load balancer applies platform-wide limits the public-IP path doesn’t.
- Direct access to non-standard protocols (SMTP, custom TCP, anything that doesn’t fit HTTP/S).
Public IPs are a paid add-on. The cost is shown in the topology wizard on hover, and on the Quotas & Pricing > Pricing > Options tab in the dashboard.
Picking a path
| Need | Use |
|---|---|
| App tier needs DB connection details | Container link |
| App-to-app HTTP call inside one env | Internal DNS |
| Quick web UI for a service | Shared LB, Open in Browser |
| Expose a single non-HTTP port | Endpoints |
| Full TCP / custom SSL / no shared limits | Public IP |