Clusters

Clusters are autoscaling groups of instances backed by a load balancer. When traffic increases, new instances are added automatically. When it drops, they are removed.

With an agent (MCP)

Connect the redu MCP, then just ask your agent.

Your agent can turn a VM it already runs into a cluster with upgrade_to_cluster (no rebuild, no redeploy, the URL does not change), inspect clusters with list_clusters, roll out a new image with update_cluster, and tear one down with delete_cluster.

Ask for high availability in plain words (“make this survive a machine failure”, “no single point of failure”) and the agent should pass high_availability: true, which is the same thing as the console’s High availability toggle. Creating a cluster from scratch (rather than from an existing VM) is still done in the console; the steps are below.

1. Create a cluster

Go to Menu → Compute → Clusters → Create Cluster.

The cluster is provisioned as a managed orchestration stack. Creation takes 2–5 minutes.

2. High availability

Set Min size to 3, or turn on High availability when upgrading an existing VM. That gives you:

• Three members on three different physical machines. Placement is automatic. A machine failure takes out one member, not your app.
• Automatic repair. If a member is destroyed, it is rebuilt without you doing anything, typically within a few minutes. The cluster keeps serving on the surviving members the whole time. Nothing to click and no alert to answer. Measured end to end on the live platform, twice: 90 seconds when a member was deleted through the API, and 4 minutes 35 seconds when it was destroyed abruptly. The difference is deliberate, redu waits for definitive evidence that a member is really gone rather than acting on a timeout, so an abrupt loss takes longer to confirm. No human involved in either case.
• Updates that keep you serving. Members are replaced one at a time, so the cluster never drops below two of three, and your URL never changes. Expect a brief blip as each member is swapped in, not a maintenance window.

Two members is not highly available, and neither is one. Three is the smallest number that survives losing one and still has a majority, so redu standardises on it.

What it costs: three members run continuously. That is the trade for redundancy, and it is worth saying out loud before you turn it on.

When you upgrade an existing VM to an HA cluster, your source VM steps out of the load balancer and becomes the machine you deploy changes from. It keeps running and is still billed. It is deliberately not one of the three: it is an ordinary VM, so it is not auto-repaired and not rolled, and serving live traffic from it would put a third of your users on the one machine nothing can rebuild.

Before you cluster: make sure the app is actually running

Upgrading a VM takes a snapshot of it immediately, and every member boots from that snapshot. If you cluster a VM whose setup has not finished yet, the snapshot captures a machine with no running service, and every member comes up looking healthy while never passing the load balancer’s health check. The cluster appears built and serves nothing.

Check the VM answers on its port first. Then upgrade.

What your image has to do

Two requirements, and a cluster quietly loses capacity if either is missed:

1. The app must start on every boot, from a service definition or a container restart policy, not from a first-boot setup script. A replaced member that boots without the app never joins the load balancer, and nothing reports an error.
2. Bind the port only when you are genuinely ready to serve. The health check can see whether the port is open, so an early bind advertises a member that is not ready yet.

3. View cluster status

From the Clusters page, each cluster shows:

• Cluster name and ID
• Current status. While a highly available cluster builds, this counts up: BUILDING 1 OF 3, then 2, then 3. Members come up one at a time, which is what places them on separate machines.
• Number of running instances
• Load balancer domain

Click a cluster to view details including individual instance health.

4. Rolling update

A rolling update replaces the image your cluster runs. Members are replaced one at a time, and each replacement is given time to come up and start serving before the next member is taken out, so the cluster never drops below its minimum capacity.

Steps:

1. Create a snapshot of an instance with the updated software (Instances → Actions → Create Snapshot)
2. Go to Clusters → Actions → Rolling Update
3. Select the snapshot from the dropdown
4. Click Start Rolling Update

Progress is shown in real time via the notification panel.

Measured twice on a 3-member cluster under continuous traffic from several clients: about 2% of requests failed during a full rolling update (43 of 1973, and 40 of 2056), in three short bursts, one as each member is swapped. Capacity never dropped below 2 members and the URL never changed.

We publish that number rather than a rounder one. An earlier single-client test recorded zero failures, but a single client is pinned to one member by the load balancer’s connection hashing, so it only ever sees one of the three swaps.

5. Delete a cluster

Go to Clusters → Actions → Delete. This removes the cluster, all instances in the group, and the load balancer. The operation cannot be undone.

If the cluster was created by upgrading an existing VM, that source VM is not deleted — it is yours, not part of the cluster. Delete it separately if you no longer need it.

API

Related

• Snapshots, create the image used for rolling updates
• Custom Domains, attach a domain to your cluster load balancer
• Clusters API, full API reference