Cluster-based rollouts keep capacity live while TurboCI promotes the next batch.

TurboCI stages updates cluster by cluster, ties promotion to health checks, and halts when a rollout stops looking safe.

1 cluster

promoted at a time during a rollout

5 retries

with 5-second spacing for health checks

clusters

yaml

services:
  web:
    instances: 3
    clusters: 2
    healthcheck:
      cmd: curl http://localhost:3000/api/healthcheck
      test: Server Running

Core behavior

How the rollout stays safe

The scheduler keeps the promotion boundary simple: stage one cluster, validate it, then move traffic.

Cluster-based updates

Instances inside a cluster update together, but clusters move one at a time to preserve healthy capacity.

Balancer-aware promotion

After a cluster succeeds, the assigned load balancer is updated so traffic only reaches healthy instances.

Zero-downtime bias

At least one healthy cluster remains in service while the next cluster is staged or updated.

Example sizing

Instances multiplied by clusters defines total capacity.

The cluster count determines rollout boundaries. The instance count determines how much capacity each boundary carries.

service-sizing

yaml

services:
  web:
    instances: 3  # 3 servers per cluster
    clusters: 2   # 2 clusters = 6 total servers
    server_type: cpx21

Total servers = instances x clusters. In this example, the fleet has six servers split into two guarded rollout units.

Promotion flow

What a rollout looks like in practice

TurboCI updates one cluster, promotes it, then repeats for the remaining capacity.

Cluster 1

All three servers update, pass checks, and are added back behind the balancer.

Cluster 2

While the second cluster updates, the already healthy first cluster keeps serving traffic.

Deployment phases

Every cluster passes through the same three phases.

Phase 1

Setup

Provision networks, keys, firewall rules, and server inventory. Scale-down cleanup happens here too.

Phase 2

Prepare

Verify SSH connectivity, sync source code, install dependencies, install runtimes, and export environment values.

Phase 3

Run

Execute preflight, start, postflight, and healthcheck hooks before the load balancer is updated.

Health checks

Promotion only happens after a passing check.

The command in `cmd` runs on the target server, and the string in `test` must appear in the output for the cluster to be promoted.

healthcheck

yaml

healthcheck:
  cmd: curl http://localhost:3000/api/healthcheck
  test: Server Running

TurboCI retries up to five times with five-second delays. If the check never passes, the rollout halts and the remaining clusters are left untouched. The command can be any shell command, not just curl.

Next step

Take the rollout model across providers

Once the update strategy is clear, the next step is duplicating the same deployment shape into multiple clouds.

Continue to multi-cloud setup