Load balancer

A load balancer is a locked virtual machine running HAProxy. You describe listeners and targets; the machine fetches that description and applies it.

What runs underneath

Layer	Technology
Proxy	HAProxy, configuration rendered from panel intent
Base	Ubuntu 24.04, locked — no SSH daemon, no shell, no accounts
Reload	HAProxy’s seamless reload; sockets are handed over, established connections are not dropped
Configuration	Pulled by a Go daemon on the VM; see Appliances
Metrics	HAProxy’s own statistics, read over its admin socket and reported to the panel
TLS	Certificates obtained by the panel and delivered with the configuration — see TLS certificates

You never see or write HAProxy syntax. You also cannot hand-edit it: the machine has no shell. If HAProxy can do something the panel does not expose, the fix is to add it to the panel.

Listeners

A listener is one routing rule: a port, an optional hostname, a protocol, and a target.

Field	Meaning
Port	The port clients connect to
Alan adı (Hostname)	Optional. Empty means “the default for this port”. Set, it means “only requests for this name”
Protocol	tcp — pass traffic through untouched. https — terminate TLS here
Hedef (Target)	A Kubernetes cluster with a NodePort, or an explicit list of address:port

Several domains on one port

Because a listener carries a hostname, one port serves many names. Three listeners on 443 for three hostnames produce a single HAProxy front end with three routing rules and three back ends.

Two rules follow from how HAProxy works, and both are enforced by the API rather than discovered at runtime:

• A port is single-protocol. All listeners on the same port are either all tcp or all https. Mixing pass-through and termination on one port is possible in HAProxy only through a two-stage loop-back arrangement; the API refuses instead of building something you would not be able to reason about.
• Routing differs by protocol. With https, TLS terminates and routing uses the HTTP Host header. With tcp, nothing is decrypted and routing uses the TLS SNI — which means a tcp listener with a hostname only works for TLS clients.

Targets

Kubernetes cluster — you choose a cluster and a NodePort. The target list is derived from the cluster’s worker nodes and stays current as workers come and go. You do not maintain it.

Servers — an explicit list of address:port. Only addresses inside the load balancer’s own private network are accepted; a load balancer reaches its own network and nothing else.

Health checks

TCP connect checks, with a configurable interval and rise/fall thresholds. A target that fails takes traffic out of rotation; the panel shows how many of each listener’s targets are up.

Traffic statistics

The panel shows, per listener: currently open sessions, sessions per second, cumulative sessions, and bytes in and out. These come straight from HAProxy’s own counters — the panel reads and displays them, it does not compute or store a time series.

Cumulative counters reset when HAProxy restarts. A configuration change is a reload, not a restart, so ordinary edits do not reset them.

Internal load balancers

A load balancer does not need a public address. Untick Dışarıya açık (Publicly reachable) and it lives entirely on its private address — useful for internal APIs, for an S3 endpoint you do not want on the internet, and for anything you reach through a Zero Trust gateway.

The choice is reversible: Dışarıya aç (Publish) attaches an address later, İç ağa al (Make internal) removes it.

Note

An internal load balancer still needs to reach the panel to fetch its configuration, so its subnet needs a gateway. “Internal” means “not published to the internet”, not “no route out”. The API refuses to create one in a subnet without egress, and says why.

TLS works on internal load balancers too — certificate issuance uses a DNS challenge, so nothing has to be reachable from the internet. See TLS certificates.

Creating one

Ağ → Yük Dengeleyiciler → Kur (Network → Load balancers → Install). Choose a name, a subnet, whether it is public, and a plan. Then add listeners.

Preconditions

Requirement	Why
A subnet with a gateway attached	The appliance must fetch its configuration
A free public address, if public	One address is consumed
For https listeners: a domain in your account with DNS hosted here	Certificate issuance uses a DNS challenge

Limits

• One appliance per load balancer today; high availability with a floating address is planned, not shipped.
• Targets must be in the load balancer’s own private network.
• Backend connections are plain — TLS terminates at the load balancer and traffic to targets is unencrypted inside your private network. Re-encryption to the backend is not implemented.
• No sticky sessions, no PROXY protocol, no mutual TLS yet.
• Health checks are TCP connect only; no HTTP health endpoints.