Fleet controller

What it is

One controller places VMs across your fleet by best fit.

The FlashVMM controller manages many hosts from one place. It reaches each host over SSH or mutual TLS, places every VM where it fits best, and merges events and usage for the whole fleet.

Why it matters

AI sandboxes arrive by the thousand. The controller turns a rack of hosts into one pool of capacity, with one API to drive it.

• Best-fit placement. A host that is full moves the request on to the next one.
• Secure by default. SSH keys, or mutual TLS with your own certificate authority.
• Fleet-wide view. Events merged and tagged by host, usage summed across hosts.

Runs on

• Linux x86_64
• Linux arm64
• macOS
• Windows x64
• Windows arm64
• Across your fleet

How it works

Add hosts, then create VMs; the controller picks the host.

CLI

flash controller serve
flash controller hosts add --name rack1 --addr ssh://ops@rack1
flash host ca create --out ca
flash host cert issue --ca ca --name rack2 --ip 10.0.0.2 --out certs
flash host cert issue --ca ca --name controller --client --out certs
flash host listen --addr 0.0.0.0:7443 --cert certs/rack2.pem --key certs/rack2.key --ca ca/ca.pem
flash controller hosts add --name rack2 --addr 10.0.0.2:7443
flash controller vms create --vcpus 2 --mem-mib 1024
flash controller events
flash controller usage

MCP

flash_controller(method: "POST", path: "/v1/flashvms", body: {"shape": {"vcpus": 2, "mem_mib": 1024}})
flash_controller(method: "GET", path: "/v1/usage")

API

POST /v1/hosts {"name": "rack1", "addr": "ssh://ops@rack1"}
POST /v1/flashvms {"shape": {"vcpus": 2, "mem_mib": 1024}}
GET  /v1/events?since=0&wait_s=30
GET  /v1/usage

The result

Your whole fleet behaves like one host.

Every VM lands where it fits, every event arrives in one stream, and usage for the fleet comes back as one bill.