Fleet

Next release

The Fleet view comes with the next Flarebox release. Flarebox 0.2.2 doesn’t have it yet.

The fleet is where every check in your organization ends up: from pqdoctor push, agents, the GitHub Action and Flarebox itself. It shows the share of servers that are post-quantum, overall and by team, the trend, what regressed and what got fixed, each server’s history, and the plan. It runs as a Worker and a D1 database on your own Cloudflare account. Nobody else operates it or sees its data, and Cloudflare’s free plan is enough for most organizations.

Flarebox deploys it, keeps its admin token, and shows it in the Fleet page of the sidebar.

Deploy it from Flarebox

Fleet → Deploy a fleet to your Cloudflare account. Pick the account and a Worker name (pqdoctor-fleet by default), then Review the deploy. Like every Cloudflare change in Flarebox, it’s a reviewed change: the review lists every API call and what changes, and nothing happens until you apply it.

Applying it:

1. Creates a D1 database with the Worker’s name, or reuses the one that’s there.
2. Applies the fleet’s migrations that the database doesn’t have yet. They’re recorded in d1_migrations, the same table wrangler d1 migrations apply uses.
3. Makes the admin token on this machine (32 random bytes) and keeps it in Windows Credential Manager. It goes to Cloudflare only as the Worker’s ADMIN_TOKEN secret; Flarebox never shows it.
4. Uploads the Worker and turns on its workers.dev address.
5. Reads the Worker back to check it, records the change in History, and connects the Fleet page to it.

The write token needs Account → Workers Scripts → Edit and Account → D1 → Edit (Tokens and permissions). A new workers.dev address can take a minute to answer.

Updating. Deploying again with the same name puts this Flarebox’s version of the fleet on the account. The database and its data stay, and only new migrations run. There’s no undo for an update, because Flarebox doesn’t keep the code it replaces; deploying again is always safe.

Removing. Undo on the first deploy in History removes the Worker. The database and its data stay, so deploying again brings everything back.

Connect to one your team runs

Fleet → Connect to a fleet: its address and admin token. Flarebox checks both by reading the fleet, then keeps the token in Windows Credential Manager. Disconnect forgets a pasted token; a fleet Flarebox deployed keeps its token, since the Worker still uses it.

What it shows

• Overview: the share post-quantum and how it moved, hosts, recent regressions and fixes; the trend; each team’s share; why the rest aren’t post-quantum (config, library or provider, and which libraries and providers); and the latest runs.
• Hosts: every server with its team, verdict and cause. Search by host, library, provider or server, and filter by team or verdict. Pick a host for its history, run by run, with where each check came from.
• Plan: the leverage plan from the latest run that sent one: the few fixes that make the most hosts and traffic post-quantum.
• Tokens: the ingest tokens agents, CI and people push with. Make one (optionally limited to a team; the fleet keeps only its hash, and Flarebox shows it once), copy the ready pqdoctor push command, and revoke one.

Open shows the fleet’s own web dashboard in the browser, with CSV exports and the certificate details below.

A host that stops answering in its latest run keeps its history but leaves the totals, so a server that was switched off doesn’t count as post-quantum or not forever.

Sending it results

From	How
Flarebox	Send Flarebox’s checks: the newest check of every host and origin Flarebox has checked, as one run from the source flarebox. The team is the zone an origin belongs to
The CLI	pqdoctor push results.jsonl --to <fleet> --token pqf_… --owners owners.toml --with-plan after any scan (Across a company)
CI	The GitHub Action with fleet-url and fleet-token
Agents	pqdoctor agent with a [fleet] section: inventory, scan, plan and push on a schedule, from inside each network

Certificates: the second axis

Key exchange is half of it; authentication is the other half. Scan with --auth (the agent and the Action do by default) and the fleet tracks, per host, whether it serves an ML-DSA certificate, and whether its chain would still fit the server’s first flight once it does. ML-DSA-44 adds about 3.7 KB per certificate (a 1,312-byte key and a 2,420-byte signature), so a 3 KB chain becomes 15 KB or more:

First flight	What it costs
≤ 3,600 B	fits: QUIC’s 3× anti-amplification limit for a 1,200-byte Initial
≤ 14,600 B	+1 round trip over HTTP/3 (QUIC), fine over TCP
larger	+1 round trip over TCP too (Linux’s initial window: 10 segments)

The fleet’s dashboard shows how many hosts serve ML-DSA, how the chains would fit with ML-DSA-44 throughout, the leaf key types and the biggest chains.

Security

• The admin token stays in Rust and the credential store. The page never receives it; no command returns it.
• Reads go to an allowlist of the fleet’s admin API (overview, hosts, host, plan, tokens); nothing else is sent with the token, and redirects aren’t followed.
• Ingest tokens push runs and read the totals (/api/v1/summary), nothing more. A token limited to a team can only report that team’s hosts.
• Flarebox deploys the fleet with the admin token. The fleet’s other mode, ACCESS = "1", relies on Cloudflare Access alone and doesn’t verify Access’s token yet, so don’t switch to it.