Scaling & redundancy

There are two independent dials. Size sets how much one control-plane replica can do. Replica count sets how many run. They’re orthogonal: change either without touching the other.

Scale up: change the size

When a control plane is busy — many nodes, many objects, heavy watch traffic — move it up a size. Each step doubles control-plane CPU, memory, and datastore capacity.

lb scale cluster home --size medium

Scaling is a control-plane operation; your nodes and workloads are untouched. We notify you as you approach a size’s envelope, so the upgrade is a decision you make, not a wall you hit.

Scale out: add replicas

A cluster runs one replica by default. Add replicas to run several control-plane instances behind one endpoint:

lb scale cluster home --replicas 3

Pricing is linear — size × replicas — because each replica is a full control-plane set consuming a full slot. A medium with three replicas is €14 × 3 = €42/mo. You pay for exactly what runs.

Redundancy vs. high availability

Replicas ≥ 2 buy control-plane redundancy: the API stays up if a replica crashes or a management node is lost.

We do not call this “high availability” yet, because true HA also requires a redundant datastore. When the datastore redundancy tier ships, the same clusters graduate to HA with no price change. We’d rather use the smaller, accurate word than the bigger, misleading one.

You have	You get	We call it
1 replica	A managed control plane	Standard
≥ 2 replicas	Survives a lost replica / management node	Control-plane redundancy
≥ 2 replicas + redundant datastore	Survives datastore loss too	High availability (coming)

Picking numbers

• Side project / homelab: small, one replica. Simple and cheap.
• Team running real workloads: medium, and add a second replica once an outage would actually hurt.
• Production across clouds: size to your object count, two or three replicas.

When in doubt, start small — both dials move up live, with no rebuild and no node disruption.