Load balancer
Spread visitors across several servers, with health checks. It runs on your own servers; traffic does not pass through Saka and there is no separate load balancer fee.
Terms
- Balancer: 1 or 2 servers that receive visitors. Two balancers in different locations keep the load balancer alive even if one goes down.
- Target servers: the servers that run your app. They must all serve the same app on the same port.
- Backup pool (optional): servers used only when all target servers are unhealthy, for example servers in another location or a maintenance page.
HTTP/HTTPS proxy mode
Recommended for websites and web apps. The balancer runs Caddy, which forwards visitors to healthy target servers.
- Automatic HTTPS: Let's Encrypt certificates for your domains are installed and renewed on their own. HTTP is redirected to HTTPS. With two balancers, an ACME challenge that does not belong to one balancer is forwarded to its partner, so each gets its own certificate without copying private keys.
- Health checks every 5 seconds on a check path of your choice (default
/). Unhealthy servers are skipped and used again as soon as they recover. - How visitors are shared: round robin (each request goes to the next server), least connections (to the least busy server), and an optional sticky setting (a visitor keeps going to the same server via a cookie, for apps that keep login sessions on the server).
- Ports 80 and 443 on the balancer must be free.
- If the Saka firewall is on for a target server, the app port is opened only for the balancer IPs.
Pointing your domain
After it is created, the detail page shows the DNS records to add at your domain manager (if you use Cloudflare, use "DNS only", the grey cloud). With two balancers, add two A records per domain:
toko.contoh.id. A 203.0.113.10 ; penyeimbang 1
toko.contoh.id. A 198.51.100.20 ; penyeimbang 2If one balancer goes down, browsers move to the other one by themselves. HTTPS turns on automatically once DNS points to the balancers; the certificate status for each domain is shown in the panel.
Firewall
Limit who can reach the site or app behind the load balancer, right at the balancer. Proxy mode only; in DNS-only mode traffic does not pass through the balancer.
- Allow only: if filled in, only these IPs or CIDRs are accepted, for example your office or VPN. Leave it empty to let everyone in.
- Deny: IPs or CIDRs that are always blocked, for example addresses attacking your site.
- Enter one IP (
203.0.113.7) or CIDR (203.0.113.0/24) per line; IPv4 and IPv6 both work. At most 200 rules per list. - Blocked visitors get HTTP 403. Rules match the IP that connects directly to the balancer. If another proxy sits in front of it (for example Cloudflare's orange cloud), the IP seen is that proxy's.
You can set the rules when creating the load balancer (the Firewall (optional) section) or change them at any time on the detail page with Edit rules; the balancers are updated within a few seconds. Via the API: PATCH /api/v1/lb/{id} with {"izinkan": ["IP/CIDR"], "tolak": ["IP/CIDR"]} (allow, deny); POST /api/v1/lb accepts the same fields.
LB address: <id>.lb.saka.work
Every load balancer gets its own DNS address, for example lbxxxxxxxxxx.lb.saka.work. This address is delegated to your balancers: a DNS server inside the balancer agent answers only with healthy addresses (TTL 30 seconds). So mobile apps, API clients, and webhooks are not sent to a dead server either.
Add a CNAME from your subdomain to that address:
www.contoh.id. CNAME lbxxxxxxxxxx.lb.saka.work.That DNS server only serves the load balancer's zone, with no recursion (other queries are refused), and listens on the balancer's public IP (port 53).
DNS-only mode
For any service, including non-web ones (TCP or UDP). There is no proxy: the balancer only acts as a name server that answers with the IPs of healthy target servers.
- Leave the domain field empty. Point your domain with a CNAME to the
<id>.lb.saka.workaddress. - HTTPS is not set up on the balancer; handle it on the target servers.
- A balancer can also be a target server at the same time (only port 53 is used).
Backup pool
The backup pool is used only when all target servers are unhealthy. If the targets and the backups are all down, DNS still answers with the main targets (fail-open), so the service comes back as soon as one of them recovers.
Notifications
The first balancer sends a notification to your Telegram when a target server becomes unhealthy and when it is healthy again. You are also notified when a load balancer is ready or fails to be created.
Test results (28 Sep 2026)
| Test | Result |
|---|---|
| HTTPS proxy, 2 balancers, real certificates, one target turned off | 148 of 150 requests succeeded |
| One balancer down | Its partner served traffic |
| DNS: target down | Removed from answers within 6 seconds |
| DNS: all targets down | Backup pool used within 8 seconds |
| DNS: target recovered | Back within 12 seconds |
| Delete | DNS records cleaned up as well |
Saka Panel is not in the traffic path or the DNS path. If Saka Panel goes down, the load balancer keeps running.
Delete
Delete it from the detail page by typing the load balancer name. The balancers are stopped, its lb.saka.work DNS records are removed, and the port permissions on the target servers are revoked. Target servers and their apps are not touched.
Weights
Each target server (and backup) can be given a weight from 1 to 100. A server with weight 3 gets roughly three times as many visitors as one with weight 1. In proxy mode, Caddy shares requests using weighted round robin (not available together with sticky sessions). In DNS mode, each answer contains one address picked at random according to the weights; because resolvers cache answers for 30 seconds, the spread of visitors follows the weights.
By region (to the nearest)
Tick Arahkan pengunjung ke yang terdekat (Send visitors to the nearest) when creating the load balancer. DNS then returns the balancer address (proxy mode) or target server (DNS mode) closest to the visitor's country. If the nearest one is unhealthy, another one is used.
- The visitor's location is read from the client subnet (EDNS Client Subnet) when the resolver sends it, otherwise from the resolver's own location.
- Server locations are detected automatically from their IPs.
- Distance is measured between the center points of countries, so this routing works at the country level, not the city level.
- Location database: IP Geolocation by DB-IP (CC BY 4.0), downloaded monthly, only on balancers that use this feature.