Proxmox VE provider
The Proxmox VE provider gives your BigFleet fleet machines to run on, on your own Proxmox cluster — no cloud account. When BigFleet decides your clusters need more capacity, the provider clones a VM from a template; when the fleet scales in, it drains and destroys it. You point it at your Proxmox cluster’s API, your nodes, and a source template, and it provisions VMs automatically — no manual VMID juggling, no by-hand clones.
You run one process per Proxmox cluster, next to BigFleet. Each process owns a single cluster’s capacity, and BigFleet dials it to request, configure, drain, and delete machines as demand moves. A machine is one Proxmox qemu VM (a single VMID on one cluster node); a BigFleet zone is a Proxmox cluster node; an instance type is a catalog entry naming a source template and the clone’s vCPU/memory.
How it behaves
- Hardened and operable. It ships as a container image and a Helm chart, runs non-root on a distroless, read-only root filesystem, and exposes liveness/readiness probes, Prometheus metrics, and structured logs. See Observability.
- Certified. It passes the full BigFleet provider conformance program — 93 certified behaviors — credential-free on every change, for the core and cloud profiles. See Certification.
- Conservative by default. A
Createsettles toIdleonly once the VM is cloned, running, and its guest agent answers; the cluster-join secret is delivered over the verified, authenticated Proxmox API (never cloud-init); TLS verification cannot be disabled — anchored on your cluster CA or a pinned certificate fingerprint; and a failed bootstrap or drain surfaces as a hard failure rather than a silently-broken node. Capacity it doesn’t own, it never touches. - On-demand only. Proxmox VMs are not preemptible: every machine is
ON_DEMANDand reports aninterruption_probabilityof exactly0. There is no spot market and noSPOTcapacity.Deletestops and destroys the VM and its disks, so the cloud profile applies.
What you need
To run it against a real cluster, have these ready:
- A Proxmox VE cluster and its API endpoint (
https://host:8006/api2/json), plus the node names you want capacity on (one process per cluster). - A least-privilege API token (
USER@REALM!TOKENID=SECRET) scoped to a dedicated resource pool. The Credentials page walks through thepveumsetup. - TLS trust material for the Proxmox API cert: your cluster CA
(
/etc/pve/pve-root-ca.pem) or the cert’s SHA-256 fingerprint. There is no skip-verify option. - A prepared template VM that joins your cluster. It must have
qemu-guest-agentinstalled and enabled andkubeletpreinstalled; the provider delivers the per-cluster bootstrap over the guest agent at Configure time. The template contract is in Configuration.
Deploy it
The provider is a container image plus a Helm chart. The path is:
- Create the API token and a resource pool with a least-privilege role,
then stage your template. The Credentials
page has the
pveumcommands; Configuration has the template contract. - Install the Helm chart, one release per cluster, pointing it at your API URL, token, CA/fingerprint, nodes, template, and your offerings (the quota of capacity it may provision). Enable durable state on a PersistentVolume so bindings survive restarts.
See Install & deploy for the full path, and Configuration for every flag and the offerings schema.
The provider also ships an in-memory fake backend used only for the
credential-free certification run. It is
testing-only and must be requested explicitly with --use-fake-backend; a
misconfigured real deployment fails closed rather than silently simulating.