Placement as a decision, not a default
Most estates are pinned to one provider by habit: the images, the scripts and the contracts all assume the same place. Moving one workload is a project; moving back is unthinkable.
The Bunny Lab makes each kernel content-addressed and deterministic, quotes its placement on cost per run across cloud, ARM, GPU, edge and bare metal, and deploys it as a shadow pin first. Promotion to canary and primary is a separate, guarded step, and rollback is rehearsed.
What you get
- A placement quote per workload: predicted runtime and cost per run on each target, with the migration cost and payback.
- Trust pools verified by replication, so untrusted capacity can serve batch work safely.
- Shadow, canary and primary rollouts with automatic rollback and a receipt each.
- The same kernel on any chipset, so the next renewal is a negotiation, not a dependency.
How it works
We quote the placement.
For the workloads the assessment priced, on the targets you are considering.
We deploy to shadow.
The kernel runs beside the original, judged by the same telemetry, with no traffic at risk.
You promote, or you don't.
Canary, then primary, each guarded; rollback is one action, and it has been tested.
BEFORE YOU START
Before you start
Do we have to move everything?
No. Placement is decided per workload. Most estates move the few workloads where the number is clear and keep the rest where they are.
Which targets are supported?
AWS, Azure, Google Cloud, Oracle Cloud, VMware, Nutanix, Proxmox, bare metal and edge, on x86, ARM and GPU.
What about the data?
Data stays where you put it. Kernels are placed next to it, and the placement quote includes the transfer cost when a move is involved.
Keep the right to leave.
Get a placement quote for the workloads your renewal depends on.