Shared Load Balancer

Shared Load Balancer

The platform uses several Shared Load Balancer infrastructure components to process incoming requests that do not connect directly through a Public IP. A Shared Load Balancer is an NGINX proxy that links client requests with applications deployed inside the platform.

In this article

Shared Load Balancer Overview

Shared Load Balancers accept requests from outside the platform and route them through the internal network to the appropriate hosted application. The service is available automatically and does not require a dedicated load balancer node in a basic environment.

Shared Load Balancer overview
Incoming requests are processed by the Shared Load Balancer and routed to the required environment.

To help protect the infrastructure against distributed denial-of-service attacks, the Shared Load Balancer limits each request source address to 50 simultaneous connections.

High Availability

The platform runs multiple synchronized Shared Load Balancers on different hosts. These instances process requests concurrently and use the same data storage, making them interchangeable when one load-balancer instance becomes unavailable.

Shared Load Balancer high availability
Several synchronized Shared Load Balancers provide multiple entry points and distribute incoming traffic.

This design creates several possible entry points for hosted environments and enables incoming traffic to be distributed efficiently.

!

Recommendation

Shared Load Balancer access is suitable for development and test environments. For high-traffic production applications, use a Public IP. A Public IP also supports additional production features such as Custom SSL and Custom Domain configuration.

Public IP compared with Shared Load Balancer
Public IP provides direct node access, while Shared Load Balancer traffic is routed through the platform infrastructure.

Backend Health Check with Shared Load Balancer

The Shared Load Balancer continuously checks backend-server availability through the NGINX upstream check module with the following parameters:

check interval=15000 rise=2 fall=3 timeout=2000 default_down=false;

These values define the following health-check behavior:

Initial statusAll containers are considered available when the Shared Load Balancer starts.
Check intervalEach node is checked every 15 seconds.
Response timeoutA check fails when no response is received within 2 seconds.
Mark node downThree consecutive failed checks mark a node as unavailable.
Mark node upTwo consecutive successful checks return a node to the available state.
✓

Tip

When an environment contains several backend application servers, dedicated load-balancer nodes are added automatically to distribute traffic and perform health checks.

Deny Access via Shared Load Balancer

The platform includes a predefined option for disabling external Shared Load Balancer access to an environment layer. This prevents access through the default environment domain without requiring a Public IP or manual firewall configuration.

The setting is available through the Access via SLB switch in the topology wizard.

Access via SLB option
Enable or disable Shared Load Balancer access for each environment layer.
!

Public IP behavior

When a Public IP is added, the platform automatically disables Access via SLB for that layer. This configuration is recommended for stronger application security. The switch can be enabled again when both connection methods are required.

When Access via SLB Is Enabled

  • Nodes can be accessed from the Shared Load Balancer through environment domain names.
  • Default service ports are available: 80, 8080, 8686, 8443, 4848, 4949, and 7979.
  • The Open in Browser button opens the relevant service, such as a database administration panel.
  • Node links are included in platform emails where applicable.

When Access via SLB Is Disabled

  • The layer is isolated from the Shared Load Balancer.
  • Pages normally opened through Open in Browser return a 403 Forbidden response.
  • Node links are removed from platform emails.
  • SSH access and endpoint-based access continue to work.

Layers with Shared Load Balancer access disabled are marked with a dedicated label in the dashboard.

No Shared Load Balancer access label
The dashboard displays a No SLB Access label for isolated layers.

Opening the default environment URL for an isolated node returns a forbidden-access page rather than the original application service.

403 Forbidden response
Default-domain access returns a 403 Forbidden response when SLB access is disabled.

Common Use Cases

  • Disable public SLB access for nodes intended only for internal use, such as database servers.
  • Prevent SLB access when a node already uses a Public IP and Custom Domain.
  • Allow traffic through an environment-level load balancer while preventing direct access to individual containers through their default URLs.

Shared Load Balancer access can remain enabled for development and testing. For production workloads, it is generally preferable to disable it and use a Public IP with a Custom Domain.