Cloud load balancing

A cloud load balancer accepts traffic for your public domain and forwards each request to one of your application servers. Health checks allow the load balancer to stop sending traffic to an instance that cannot serve requests.

Coolify deploys and manages the application instances. You configure the load balancer, backend targets, TLS settings, health checks, DNS, and network rules with your infrastructure provider.

Before you begin

Complete Multi-server Deployments and verify the application on every server.
Create a health endpoint that returns a successful response when the instance is ready to receive traffic.
Decide whether the load balancer will connect directly to a mapped host port or through the Coolify Proxy on each server.
Put the load balancer and application servers on a private network when your provider supports one.
Decide where TLS terminates. A common setup terminates TLS at the cloud load balancer and sends HTTP traffic over a private network to the application servers.

The examples below use app.example.com as the public domain, port 443 on the load balancer, and /health as the health-check path. Replace them with values for your application.

Choose how the load balancer reaches each server

Origin path	Use when	Trade-off
Direct host port	The load balancer serves one application or you want to bypass the proxy on each application server	Requires a host port mapping and strict firewall rules; host port mappings disable Coolify rolling updates for that application
Coolify Proxy	The application servers host several domains or you want Coolify-managed routing on each server	Adds one proxy hop and requires the load balancer to preserve the request host name

Map the same host port on every application server. For example, 8080:3000 maps port 8080 on each server to port 3000 in the application container.

Open Configuration > General for the application.
Add the mapping to Ports Mappings.
Remove the public domain from Domains because requests will bypass the Coolify Proxy.
Redeploy the application and test http://<server-address>:8080 from a network that can reach the server.
Add each server address and port 8080 as a backend target in the load balancer.

Restrict the mapped port

A mapped host port can expose the application directly. Configure the provider firewall or server firewall so the port accepts traffic only from the load balancer or its private network.

Configure the load balancer

Create the load balancer with your infrastructure provider, then configure:

A public listener on port 443 with a certificate for app.example.com.
A backend pool containing every application server and the port selected above.
An HTTP health check for /health on the same backend port. For the Coolify Proxy path, configure the health check to send Host: app.example.com.
A forwarding policy or algorithm appropriate for your traffic.
Optional sticky sessions only when the application cannot yet keep session state in a shared store.

The exact labels vary by provider. Confirm that a healthy response adds the server to rotation and a failed response removes it.

Point DNS to the load balancer

At your DNS provider, point app.example.com to the public address or hostname supplied by the load balancer. Do not point the public record at one of the application servers.

Wait for the DNS change to propagate, then open https://app.example.com and confirm that the certificate is valid.

Verify traffic and failover

Confirm that every backend target is healthy in the load balancer dashboard.
Send several requests to https://app.example.com and check application logs on the servers to confirm that more than one instance receives traffic.
Stop the application on one additional server from Configuration > Servers.
Confirm that the load balancer marks that backend unhealthy and the public domain continues to respond through another server.
Deploy the stopped server again and confirm that it returns to the healthy backend pool.

Operating considerations

Adding or removing an application server in Coolify does not update the cloud load balancer. Keep its backend pool in sync with the application's Servers page.
Store sessions, uploads, queues, caches, and other shared state outside the application containers.
Restrict backend ports to the load balancer and required administrative networks.
Monitor the public endpoint from outside your infrastructure as well as the individual servers.
Test a complete server failure, not only a stopped container, before relying on the setup for availability.

For a provider-specific example, read Load Balancing on Hetzner. For a custom Traefik configuration instead of a provider-managed load balancer, read Traefik Load-balancing.