Skip to content

Providers

BigFleet decides which machines should exist. Capacity providers are what actually create, configure, drain, and delete them on a real substrate. BigFleet never talks to a cloud API directly — it dials a provider you run, and the provider does the work.

The canonical, always-current registry lives at bigfleet-providers.lucy.sh. This page is the orientation; that site is the list.

What a provider is

A provider is a small process implementing the CapacityProvider contract — six RPCs, no Watch:

Create · Configure · Drain · Delete · Get · List

Reconciliation is pull-based: BigFleet learns the real state of the world through List + Get, never a streamed watch. You run the provider as a container alongside BigFleet, ship it with a Helm chart, give it scoped credentials for its substrate, and BigFleet dials out to it.

The ecosystem

There are 12 conformance-certified providers today, spanning hyperscalers, regional clouds, and bare metal. Pick yours:

Each chip links to that provider’s overview on bigfleet-providers.lucy.sh, where its pages cover install, configuration, credentials, observability, security, and how it’s certified.

Out of tree, by design

BigFleet ships the provider contract, the dial-out client, and a test-only fake — never a real provider. Real providers live in their own repositories. Kubernetes spent years undoing in-tree cloud providers; BigFleet doesn’t repeat that mistake. The payoff is operational: a provider’s release cadence is decoupled from BigFleet’s. When BigFleet ships a new version you don’t redeploy your provider; when your provider ships you don’t coordinate with BigFleet maintainers.

Writing your own

Covering a new substrate doesn’t mean re-solving the hard parts. Providers are built on providerkit, a shared library that gets fencing, idempotency, async dispatch, transition timeouts, and the machine-state contract right once — so a new provider is mostly a small backend describing how to create, configure, and drain an instance on your substrate.

Correctness is gated by a conformance suite covering 93 behaviors across 11 areas — idempotency, transitional-state recovery, cursor correctness, drain-grace handling, and more. Passing it is what lets a provider claim compatibility. Point the suite at your endpoint:

Terminal window
make conformance TARGET=host:port

Start from the provider author guide, which walks the contract, the conformance categories, and the providerkit backend interface end to end.