Skip to content
BigFleet Providers

BigFleet Providers

Capacity providers you deploy alongside BigFleet to provision and reclaim the machines your fleet runs on — one per substrate, each conformance-certified.
Browse all providers How it's certified GitHub

What you get

You already run BigFleet to autoscale your fleet. BigFleet decides which machines your Kubernetes clusters need — but it doesn’t touch your cloud account. A capacity provider is the piece that does: you deploy it next to BigFleet, point it at your substrate, and it provisions, configures, drains, and reclaims real machines automatically as your fleet’s demand moves.

You run it as a container, ship it with a Helm chart, give it scoped credentials, and BigFleet dials it. From then on, machines appear and disappear to match your fleet — no glue scripts, no manual capacity ops.

Providers

One provider per substrate — a container image and a Helm chart you deploy one process per region (or location, or zone), pointed at your account and a base image. Pick yours:

AWS EC2 Azure DigitalOcean GCP (GCE) Hetzner Cloud Latitude.sh libvirt Oracle Cloud (OCI) OVHcloud Public Cloud Proxmox VE Scaleway UpCloud

Each provider’s pages cover install, configuration, credentials, observability, security, and how it’s certified. See the full providers directory.

How it’s certified

Every provider here is certified by passing the same suite — no exceptions, no self-attestation. Each clears the upstream authoritative baseline plus an extension suite, against 93 conformance behaviors across 11 areas, credential-free on every change. That covers the things you’d otherwise have to take on faith: a failed bootstrap or drain surfaces as a visible failure rather than a silent false “ready”; launches are idempotent; inventory stays consistent.

See the conformance program for what’s checked, and each provider’s certification page for how to reproduce the verdict yourself.

How it works (in one line)

BigFleet is the client; each provider is a gRPC server it dials to create, configure, drain, and delete machines. You don’t write any of that — you deploy a provider and configure it.

Building a provider?

If you’re adding support for a new substrate rather than operating one, the authoring path lives a layer down — every provider is built on a shared library that gets fencing, idempotency, and the machine contract right once, so you only write substrate-specific logic.

You don’t have to merge it here, either. providerkit is a public Go module, so an out-of-tree provider you keep private — for an internal or proprietary substrate — is a fully supported, first-class path. The providers listed here are a curated, certified-conformant starter set to deploy or copy from, not a requirement.