NGINX Balancer

NGINX Load Balancer

NGINX is a high-performance HTTP server, reverse proxy, and load balancer. On the platform, the managed NGINX load-balancer stack automatically detects application-server backends, adjusts configuration according to available resources, performs backend availability checks, and integrates with platform management and SSL automation.

In this article

NGINX Load Balancer Features

Automatic backend detectionApplication-server backends inside the environment are detected and included in the balancing configuration automatically.
Automatic tuningThe managed stack can optimize NGINX configuration according to available resources and current load.
Health checkingBackend availability is checked before routing requests so unavailable servers can be avoided.
SSL automationThe stack is compatible with platform automation for Let’s Encrypt and custom SSL certificates.
Platform managementThe stack is fully integrated with the dashboard for configuration, scaling, restart, redeploy, and other lifecycle operations.
Regular updatesThe managed NGINX image receives platform-maintained version and security updates.

Deploy NGINX Load Balancer

  1. Log in to the platform dashboard.
  2. Click New Environment.
  3. In the topology wizard, open the Balancing section and select NGINX.
  4. Add the required application servers and other environment nodes.
  5. Configure the resource limits and, when required, attach a public IP address to the NGINX layer.
  6. Enter the environment name and click Create.
✓

Public IP

A public IP is useful when traffic must reach the NGINX balancer directly instead of passing through the platform Shared Load Balancer, or when a particular SSL, protocol, or networking scenario requires direct access.

Load-Balancing Methods

NGINX supports several methods for distributing requests across backend servers.

Round RobinRequests are distributed sequentially across available servers. This is the default NGINX method when no other algorithm is specified.
Least ConnectionsThe next request is routed to the backend with the fewest active connections.
IP HashA hash based on the client IP is used to keep requests from the same client on the same backend where possible.
Weighted BalancingBackend weights can influence how much traffic each application server receives.

Example Upstream Configuration

upstream application_servers {
    server 10.0.0.10:80;
    server 10.0.0.11:80;
    server 10.0.0.12:80;
}

server {
    listen 80;

    location / {
        proxy_pass http://application_servers;
    }
}

Configuration Files

The managed NGINX load balancer uses platform-generated configuration files for automatic backend discovery and SSL handling. Configuration can be reviewed and adjusted through the dashboard Configuration File Manager or through SSH.

/etc/nginx/nginx.confMain NGINX configuration file.
/etc/nginx/nginx-jelastic.confPlatform-managed configuration used for dynamically detected backend servers.
/etc/nginx/conf.d/Contains additional virtual-host, SSL, upstream, and platform-specific configuration fragments.
!

Managed configuration

Some NGINX configuration is generated automatically by the platform. Before making permanent custom changes, confirm that the selected file is intended for manual customization so redeploy, scaling, or automatic topology updates do not overwrite the modification.

Backend Servers

Application servers in the same environment are normally detected automatically. When the application layer scales horizontally, the managed NGINX stack can update the backend list so newly added application servers participate in traffic distribution.

NGINX can also proxy traffic to manually configured backends when a custom topology requires it. A standard backend entry follows this form:

upstream custom_backend {
    server 10.0.0.20:8080;
    server 10.0.0.21:8080;
}

Backend Health Checks

The managed NGINX load-balancer image performs backend availability checking before requests are routed. Standard NGINX also supports passive health checking through parameters such as max_fails and fail_timeout.

upstream application_servers {
    server 10.0.0.10:80 max_fails=3 fail_timeout=30s;
    server 10.0.0.11:80 max_fails=3 fail_timeout=30s;
}

When a backend repeatedly fails, NGINX can temporarily avoid routing new requests to that server and retry it later.

SSL and HTTPS

NGINX can terminate HTTPS connections at the load-balancer layer and forward requests to application servers. The managed stack is compatible with platform automation for Let’s Encrypt and custom SSL certificates.

For deployments that require a custom domain and direct SSL termination on NGINX, attach a public IP when required, point the domain to that address, and install the appropriate SSL certificate through the platform-supported workflow.

Expected Result

NGINX is deployed in front of the application layer and distributes incoming requests among available backend servers. Backend discovery, resource-aware configuration, health checking, SSL integration, and environment lifecycle operations are handled through the managed platform stack.

Important Notes

  • The managed NGINX image is designed specifically for the platform and integrates with automatic backend discovery.
  • Round Robin is the default NGINX load-balancing method when no alternative method is configured.
  • Least Connections, IP Hash, and weighted balancing can be used for different traffic-distribution requirements.
  • Some configuration files are platform-managed and can be regenerated after topology changes.
  • A public IP may be required when traffic must reach the NGINX node directly.
  • Use platform-supported SSL automation for Let’s Encrypt or custom certificates.