Skip to content
Beta

Get started with load balancers

A load balancer is a public address in front of your instances, virtual machines and apps. Each listener opens one public port and forwards it to a target group: the targets behind it, with a balancing rule and a health check that takes a failing target out of rotation. Every load balancer rate-limits floods and bans abusive sources, with the protection profile you pick.

For websites and APIs over HTTPS on the standard port, use a web app or a Kubernetes cluster's managed gateway instead: a load balancer on the shared IP answers on ports from 40000 to 49999, not on 443.

Before you start

  • A workspace role of Owner or Admin. Developers and viewers see load balancers read-only.
  • The targets, such as two virtual machines, running on your workspace's network.

1. Create the load balancer

Open Load balancers and choose New load balancer. The form has six steps on one page. The first three make the load balancer:

  1. Basics: its Name, up to 63 characters on one line, such as api-edge, and the Network its targets live on.
  2. Tier: Free, on your workspace's shared IP, ports 40000–49999. The tiers with a dedicated IPv4 address show Not offered yet.
  3. Protection: Standard, sensible for most services, or Strict, for exposed databases and admin ports.

Select Create load balancer. The next three steps open once it exists, and each is saved as you finish it.

2. Add a target group, targets and a listener

  1. Target group: the protocol and port your targets listen on, the balancing rule and the health check. Select Add target group.
  2. Targets: the instances, apps or addresses on the load balancer's network the group forwards to. Add at least one.
  3. Listener: the public port clients connect to, forwarded to the target group. Select Create listener and finish.

The Summary beside the steps tracks each one. Go to load balancer opens it at any point; what you skipped can be added later from its Target groups and Listeners tabs. A new load balancer shows Pending, then Provisioning, then Ready.

3. Connect

Every load balancer has a DNS name of its own under lb.sahabti.app. The Listeners tab shows each listener's Public endpoint, the DNS name with the listener's port:

bash
nc -vz api-edge-k3x9mq.lb.sahabti.app 40006

To use your own domain, point it at the DNS name with a CNAME record; clients still connect with the listener's port.

With PromptOps

In a workspace with PromptOps on, ask in the chat. It asks before it creates or changes anything:

  • "Create a load balancer called api-edge in front of web_1 and web_2 on port 8080."
  • "Is any target of api-edge unhealthy?"
  • "Only let 203.0.113.0/24 reach the listener of api-edge."
  • "How much traffic did api-edge process this month?"

With the API or MCP

Create an API token with the loadbalancer actions, find your network's id with GET /v1/networks?orgId=$WORKSPACE_ID, and save the load balancer as load-balancer.json:

json
{
  "orgId": "<workspace id>",
  "name": "api-edge",
  "networkId": "<network id>",
  "tier": "free",
  "protection": "standard"
}
bash
curl -X POST https://api.sahabti.com/v1/load-balancers \
  -H "x-api-key: $SAHABTI_TOKEN" \
  -H "Content-Type: application/json" \
  -d @load-balancer.json

Over MCP, create_load_balancer takes the same fields, then add_lb_target_group, add_lb_target and add_lb_listener complete it. A change is applied within seconds: read the load balancer back until pendingChanges is false.

What it costs

A Free load balancer includes its listeners and a monthly traffic allowance, and is throttled past it until the month rolls over. How many load balancers a workspace holds depends on its owner's plan. See Load balancers, Plans and pay as you go and the pricing page.

First checks

  • The load balancer shows Ready, and its Health shows Healthy.
  • On Target groups, every target is healthy; an unhealthy one says why.
  • A connection to the Public endpoint reaches a target.
  • Monitoring charts its connections and traffic.

Next steps