Load balancing is the dedicated dispatch of incoming traffic across several backend workers. On Stack Harbor PaaS the work is done by a balancer node — added to the environment topology automatically whenever you scale an application tier, and that you can also add and scale manually.
The platform runs balancing on two layers, and it helps to keep them separate when you reason about traffic flow.
The two layers
| Layer | Purpose | Managed by |
|---|---|---|
| Infrastructure layer | Routes inbound requests from the public internet to the right environment | Shared Load Balancer, platform-operated |
| Application layer | Distributes requests inside an environment across the replicas of one tier | An environment-level balancer node |
When a node has a public IP attached, traffic to that node bypasses the Shared Load Balancer and lands directly. Everything else hits the Shared Load Balancer first.
The five managed balancer stacks
The PaaS provides out-of-the-box support for five balancer stacks at the application layer:
- NGINX — TCP/UDP and HTTP reverse proxy. Layer 7 balancing and content caching. The default in most environments, modular and resource-efficient.
- HAProxy — Event-driven proxy for TCP and HTTP. Smart persistence, stable memory under high concurrency, useful for DDoS-tolerant front ends.
- Varnish — Caching HTTP reverse proxy bundled with NGINX as an HTTPS front so it composes with custom SSL. Offloads delivery of static and cacheable dynamic responses.
- Apache balancer — Module-based balancer with broad customisation. A natural choice when the rest of the tier is already Apache.
- LiteSpeed Web ADC — Commercial ADC with HTTP/3 / QUIC, a web application firewall, Layer 7 anti-DDoS filtering, caching, acceleration, and offload features.
Running an application tier behind a balancer with two or more nodes is the standard production pattern — it gives you redundancy and removes the single application server as a failure point.
Backend health checks
Each environment-level balancer ships with a default health-check implementation:
| Balancer | Default check |
|---|---|
| NGINX | TCP check on the upstream port before each routing decision; on failure, the next node in the layer is tried |
| HAProxy | TCP check every 2 seconds, results stored in an in-memory state table |
| Varnish | URL probe once per minute with a 30 s timeout, 5-sample window, 2-failure threshold |
| LiteSpeed ADC | TCP check on the internal IP every second with a 1 s timeout, at the Worker Group level |
| Apache balancer | None by default — configure mod_proxy_hcheck if you want active probing |
The defaults are reasonable starting points. Adjust interval, timeout, and failure threshold from the balancer’s configuration files through the dashboard or over SSH.
When to add a balancer manually
The balancer is added for you when you scale an application tier to more than one node. Three cases call for adding one earlier or by hand:
- TLS at the balancer. Terminate HTTPS once and forward HTTP internally — cleaner certificate handling, lighter app servers.
- Edge controls. Authentication, IP allow/deny, rate limiting, request rewriting — these are tidier on a dedicated balancer than spread across app nodes.
- Caching. A Varnish or NGINX cache layer in front of dynamic backends keeps response times flat under load.
You can add a balancer to a single-app-server topology from the topology wizard’s Balancing block.