The starting point
Our development cluster runs Coral’s own API, our consoles and our deployment tooling. It is a typical small team cluster: a system machine that Azure requires, and two worker machines for the apps. Like most clusters, it was sized for safety, not for what the apps actually used.
On 4 October 2026, when Coral was connected3 machines · 10 CPU · $368.65 a month
Connecting Coral
One zoorikctl command installed Coral’s agent in the cluster. Two days later we gave Coral permission to remove machines, in this cluster only. From then on Coral worked on its own, and we watched.
Sets each app’s CPU and memory to what it really uses, and raises it when an app needs more.
Spots a machine the apps no longer need, moves the apps off it and removes it.
Swaps machines for a cheaper set that still fits every app, new machine first.
What Coral did
Node optimization: a spare worker removed
6 OctCoral worked out that the apps would fit on fewer machines. It moved them to the remaining machines and removed one 4-CPU worker, on its own, in under 10 minutes. Nobody switched anything on. Apps that run a single copy restarted once on another machine, and every app was running again afterwards.
Workload optimization: apps sized to what they use
from 8 OctWe switched workload optimization to automatic. By 12 October Coral had right-sized 14 of the cluster’s apps. Most were reserving more than they used; one app needed more memory, and Coral gave it more.
CPU the apps reserve45% less
Before0.78 cores
Now0.43 cores
Memory the apps reserve16% less
Before6.4 GiB
Now5.4 GiB
Rebalancing: one click, a cheaper machine
12 OctWith one click, Coral swapped the remaining worker for a cheaper machine of the same size, chosen from Azure’s prices. Azure built the new machine in under 2 minutes; Coral moved the apps one copy at a time and then removed the old machine. 8 minutes 36 seconds from start to finish.
How the apps came through
Moving an app to another machine means stopping it in one place and starting it in another. Here is what that meant for our apps during the rebalance on 12 October, measured from the moment the old copy stopped to the moment the new one was ready.
Backend service A82 s
Backend service B78 s
Deployment tool, part 154 s
Deployment tool, part 230 s
Deployment tool, part 329 s
Deployment tool, part 418 s
Deployment tool, part 518 s
Cache A17 s
Cache B16 s
Cache C16 s
Certificate sync5 s
0 seconds for the 6 apps that run two copies, including Coral’s API and both of our consoles: one copy was always running while the other moved.
What this means: an app that runs a single copy is down for a short time whenever it moves, with Coral or without it. Here that was 5 to 82 seconds. Apps that must never pause should run two copies, and Coral keeps one of them running. When the spare worker was removed on 6 October, single-copy apps also restarted once; those times were not measured.
How the apps stayed safe
Nothing was removed until its replacement was ready and its apps had moved.
Every move kept within each app’s own limits, so apps that run two copies always kept one running.
Where a faster move could have put an app at risk, Coral chose the safe one.
The result
Connected4 Oct
Node optimization6 Oct
Rebalancing12 Oct
Today12 Oct
| Measure | 4 Oct | 12 Oct | Difference |
|---|---|---|---|
| Machines | 3 | 2 | 1 fewer |
| CPU | 10 | 6 | 4 fewer |
| Per month | $368.65 | $154.76 | $213.89 less |
| Per year | $4,423.80 | $1,857.12 | $2,566.68 less |
$213.89 of $368.65 a month
Zoorik’s own development cluster on Azure Kubernetes Service, 4 to 12 October 2026. Costs are Azure pay-as-you-go list prices for the cluster’s machines at 730 hours a month. App figures cover the cluster’s own apps. Results depend on each cluster’s apps and machines.