Create a Load Balancer from the Deploy page in my.cubepath.com. Deploy is quick — you add listeners and backend targets afterwards from the load balancer's tabs.
NoteYour account must be verified before you can deploy.
What it's for
A load balancer gives you one stable public address in front of several servers, and stops sending traffic to any of them that fails a health check. That buys two things at once: you can lose a backend without losing the service, and you can add or remove backends without touching DNS.
Deploy
- 1Pick regionChoose a region. Load Balancers are available in Miami (MIA), Houston (HOU) and Barcelona (BCN).
- 2Choose a planEach plan sets the maximum targets, listeners and connections per second, with monthly and hourly pricing shown.
- 3Attach a private network (optional)Attach a private network so the load balancer reaches targets by their private IP. Targets must be on the same network.
- 4Name and deploySet the name (and optional label), then click Deploy Load Balancer.
ImportantListeners, backend targets and health checks are configured after deploy, from the Listeners tab — not during creation. A freshly deployed load balancer accepts no traffic until you add a listener.
Distribution algorithm
In Settings, choose how traffic is spread across targets:
| Algorithm | How it behaves | Use it when |
|---|---|---|
| Round Robin | Each new connection goes to the next target in turn | Backends are identical and requests cost roughly the same |
| Least Connections | New connections go to the target holding the fewest | Request duration varies a lot — long-lived connections, streaming, slow queries |
Round robin is the sensible default. Least connections is what you want the moment some requests take far longer than others, because round robin will happily pile new work onto a backend that's already stuck on ten slow requests.
Sticky sessions
Sticky sessions route repeat requests from the same client to the same target, using a cookie you name with a TTL you set.
Turn it on when your application keeps session state in memory on each server. Better still, don't need it: an application that keeps sessions in a shared store (a managed Valkey, for example) load balances cleanly, survives a backend dying without logging everyone out, and lets you scale without reshuffling users.
NoteWith stickiness on, removing a target logs out the clients pinned to it. Weigh that against the convenience.
Floating IP
The load balancer needs a floating IP to be reachable from the internet. Assign one in Settings; unassign it to take the load balancer off the public internet without deleting it.
Because the address is a floating IP, it belongs to your organization — you can keep the same public address across a rebuild, and DNS never has to change.