Self-hosted. Open source.

Burst incredible. No hassle.

When a pod can’t be scheduled, Cloudburst adds the cheapest node across multiple clouds. One brain (CloudBroker), one set of hands (the Autoscaler). No manual resizing. No lock-in.

See architecture · Read the intro

  • Cost-aware — cheapest VM that fits
  • Multiple providers — e.g. GCP, AWS, Azure, Hetzner, Scaleway, DigitalOcean, OVH (more added over time)
  • Scale down — cordon, drain, delete when empty
Node lifecycle: Pod unschedulable → Cloudburst controllers (NodePool, NodeClass, NodeClaim) → CloudBroker → VM provisioned → Bootstrap → Node Ready. Scale-down: empty + TTL → cordon, drain, delete.
Node lifecycle: NodePool + NodeClass; unschedulable → CloudBroker → NodeClaim → provision → bootstrap → Node Ready; scale-down when empty.

A new node, with peace of mind.

Get a burst node in minutes. The cluster picks the cheapest cloud.

Unschedulable pod → Autoscaler asks CloudBroker for the cheapest instance → provisions that VM on the right cloud → bootstrap (Tailscale, kubeadm join) → node Ready. When the node’s empty long enough, it’s torn down. Billing stops.

What you get
Burst
  • NodePool + NodeClass
  • NodeClaim per burst node
  • Tailscale + kubeadm join
  • Scale-down when empty
Node lifecycle: Pod unschedulable → DemandDetector → NodePool → CloudBroker → NodeClaim → VM provisioned → Bootstrap (Tailscale, kubeadm) → Node Ready → scale-down (empty + TTL) → cordon, drain, delete.
Node lifecycle: unschedulable → DemandDetector → NodePool → CloudBroker → NodeClaim → provision → bootstrap → Node Ready → scale-down when empty.

Simple. Fast. Yours.

Simple

Define NodePool (policy, max price, scale-down TTL) and NodeClass (credentials, Tailscale). The system creates a NodeClaim and VM when a pod can’t be scheduled.

Fast & easy

CloudBroker + Tailscale + provider credentials. kubectl apply CRDs and samples. Watch the controller provision a VM and join the node.

Cost-aware

CloudBroker recommends the cheapest instance that fits. No manual picking. No lock-in. You run both; you own the data.

Use cases

When Cloudburst fits best.

Cost-optimised batch & CI

Run batch jobs, CI pipelines, or ML training that don't fit your base cluster. Cloudburst adds the cheapest node across clouds when needed, removes it when done.

Cross-cloud hybrid

Keep the control plane in one cloud (e.g. EKS) and burst workers to cheaper providers (Hetzner, Scaleway) via Tailscale. Best of both worlds.

EU compliance

Run sensitive workloads in EU regions (Hetzner, Scaleway, OVH, GCP eu-west) while benefiting from cross-provider price comparison.

Dev/staging scale-to-zero

Small base cluster; burst nodes only when devs run integration tests or staging deploys. Scale down to zero when idle.

Event-driven spikes

Handle one-off spikes (product launches, campaigns, data migrations) without over-provisioning year-round.

Supported providers

Burst to the cheapest node across multiple clouds. More providers are added over time.

AWS GCP Azure Hetzner Scaleway DigitalOcean OVH

Cloudburst vs alternatives

Same problem (unschedulable pods → provision nodes → deprovision when idle). Different focus.

Aspect Cloudburst Karpenter Cluster Autoscaler
Provider scope Multi-cloud (GCP, AWS, Azure, Hetzner, Scaleway, DigitalOcean, OVH) Primarily AWS (EKS) Per-provider (node groups)
Cost selection Cheapest instance across providers (via CloudBroker) Spot/preemptible within same cloud Resize existing node groups
Cross-cloud burst Yes — e.g. EKS control plane, Hetzner burst nodes (Tailscale) No — nodes in same cloud as cluster No — scales node groups in-place

Cloudburst is built for multi-cloud cost optimisation and cross-cloud burst. If you run a single cloud (e.g. EKS only), Karpenter or Cluster Autoscaler may fit better.

Articles

Four-part intro: problem and product, how it works, the interface (NodePool, NodeClass, NodeClaim), scope and run.

Architecture

DemandDetector, NodePool and NodeClaim controllers, bootstrap and scale-down flow.

Examples

With CloudBroker and Tailscale running, apply the CRDs and sample manifests. A high-resource pod triggers provisioning; kubectl get shows the result.

Got questions? Here’s the answers.

What is Cloudburst?

Cloudburst is a Kubernetes controller that adds burst nodes when pods can’t be scheduled. It asks CloudBroker for the cheapest VM that fits, provisions it on the right cloud (e.g. GCP, AWS, Hetzner, Scaleway — more coming), and bootstraps it with Tailscale + kubeadm join. When the node is empty long enough, it cordons, drains, and deletes the VM.

What do I need to run it?

CloudBroker (for recommendations), Tailscale (for networking), and provider API credentials. You define NodePool and NodeClass; the system creates NodeClaims and VMs. See the repo for config/samples/ and make kind-setup-and-deploy.

How much does it cost?

It’s open source. You run it. You pay for the VMs you burst to — and the controller picks the cheapest one that fits. No monthly fee to us.

Can I scale down?

Yes. When the node has been empty for ttlSecondsAfterEmpty (set in NodePool), the controller cordons, drains, and deletes the VM. Billing stops.

Get running in a few steps

Prerequisites: CloudBroker, Tailscale, provider credentials.

1 cp .env.example .env
2 make kind-setup-and-deploy
3 Apply NodeClass + NodePool

See the repo for full manifests and per-provider samples.

How they work together

Powered by CloudBroker: the recommendation API that knows prices across multiple clouds. Cloudburst asks; CloudBroker answers.

flowchart LR
    Cluster --> Cloudburst
    Cloudburst -->|"POST /api/recommendations"| CloudBroker
    CloudBroker -->|"cost recommendation"| Cloudburst
    Cloudburst -->|"provision"| ChosenProvider["Chosen provider"]
    ChosenProvider --> NodeReady["Node Ready"]
          

Burst incredible. One repo.

Your cluster. Your clouds. No lock-in.

View on GitHub