Skip to content

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 Create settles to Idle only 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_DEMAND and reports an interruption_probability of exactly 0. There is no spot market and no SPOT capacity. Delete stops 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 the pveum setup.
  • 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-agent installed and enabled and kubelet preinstalled; 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:

  1. Create the API token and a resource pool with a least-privilege role, then stage your template. The Credentials page has the pveum commands; Configuration has the template contract.
  2. 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.