Container ports | Stack Harbor Documentation

The Ports tab in the container layer settings documents how the platform exposes container ports through the Shared Load Balancer (SLB). The platform opens a default set of ports for every container, and you can extend access with endpoints or a public IP.

Default ports

Every container has the following ports open by default. The Port-on-SLB column is what external clients hit; the Backend Port column is where traffic is forwarded inside the container.

Port on SLB	Backend Port	Frontend SSL	Backend SSL
80, 8080, 8086	80	no	no
4848	4848	yes	yes
8443	8443	yes	yes
4901–4910	4901–4910	yes	yes
443	80	yes	no
4949	4949	yes	no
7979	7979	yes	no

Summary of common cases:

80, 8080, 8686 — proxy HTTP traffic to port 80 inside the container.
443 — terminate TLS at the SLB and forward plain HTTP to port 80 inside.
4848, 8443, 4901–4910 — TLS end to end (frontend and backend both encrypted).
4949, 7979 — TLS at the SLB, plain backend.

Opening additional ports

When the default set isn’t enough, you have two options:

Endpoints — map an internal container port to a random external port through the Shared Load Balancer. Configure them in Settings > Endpoints on the environment. Useful when you need to expose, for example, a custom TCP service that doesn’t sit on a standard HTTP port.
Public IP — attach a dedicated IPv4 or IPv6 to a container. Every port on the container becomes reachable directly, bypassing the SLB. Use this when the SLB’s routing model doesn’t fit, for example when you need to control the public IP that clients see.

In either case, bind your application listener to the internal or external address the platform exposes.

Ports auto-redirect

The platform automatically forwards incoming HTTP/HTTPS requests to the application running inside the container, even if your app listens on a non-standard port. The mechanism:

When the container starts, the platform scans the TCP ports it listens on.
Common service ports (SSH, mail, databases) are filtered out.
The first remaining port becomes the container’s HTTP entry point. Incoming HTTP/HTTPS traffic on the SLB defaults is forwarded to that port.

The scan runs on every container start, so your application is reachable through the SLB the moment it’s deployed — no manual port mapping required.

Overriding auto-redirect

Sometimes auto-redirect picks the wrong port — for example, it might land on an admin panel you’d rather not expose, or your app’s main listener takes a few seconds longer to start than another port. Override with environment variables.

JELASTIC_EXPOSE

Set JELASTIC_EXPOSE in the container’s Variables to control auto-redirect explicitly:

0, DISABLED, or FALSE — disable auto-redirect entirely.
A number in the 1–65535 range — pin the entry point to that exact port.
Any other value — auto-redirect runs as usual.

JELASTIC_PRIORITY_PORTS

For containers that take a while to bring up their main listener, JELASTIC_PRIORITY_PORTS is a comma-separated list of ports the platform checks first. The platform configures the entry point to the first active port it finds, which can shave seconds off container startup compared to the full scan.

Rules:

If JELASTIC_EXPOSE is set to an exact port, JELASTIC_PRIORITY_PORTS is ignored.
If none of the JELASTIC_PRIORITY_PORTS are listening when the platform checks, the default auto-redirect scan runs.

REDIRECT_EXCLUDE_PORTS

For Node.js application servers, REDIRECT_EXCLUDE_PORTS (also comma-separated) lets you explicitly remove ports from the auto-redirect candidate list — useful when a process listens on port 80 for one reason but you want auto-redirect to point elsewhere.

Further customization

For finer control over container accessibility — IP-based access rules, port-level deny lists, protocol restrictions — see the container firewall reference.