Governance · Fleet
Fleet holds the persistent state behind every client connection: which servers a profile names, which device it is enrolled on, and which secrets it needs — as references, never as values. The profile is only valid while the scope it is bound to stays admitted.
The order matters. A profile that has not been bound to an admitted scope cannot be projected onto a machine, and a projection that cannot resolve a required secret does not partially succeed.
Step 1
A device-flow enrolment issues a per-device key. The key is revocable server-side, and revoking it invalidates every profile that depends on it.
Step 2
A profile is only valid against a scope Guard has admitted, at a specific binding epoch. A profile with no admission is not distributable — that is a design decision, not a gap.
Step 3
Each entry records a transport, a platform constraint, and where it was imported from. No resolved paths, no device-local state, no secret values — ever.
Step 4
Before anything is written, the profile is analysed against the machine: is the command present, is the platform right, is every required secret resolvable here.
Step 5
A server whose secret cannot resolve is held with a named reason. Fleet does not half-apply a profile and leave you to discover which half.
Below is a whole profile: the servers it connects, the secret bindings it needs, and the plan Fleet produced when it was projected onto a machine that was missing one of them. Read the middle card carefully — the values are not there, and that is the feature.
Three connected tools, described declaratively. The profile is canonically serialized, so its hash is the same on every machine that holds it.
A binding is a name, a provider class, and whether the connection can start without it. The value is resolved on the enrolled device at connection time and is never transmitted, stored, or synchronized.
| Binding | Provider | Value |
|---|---|---|
| ISSUE_TRACKER_TOKENsb_4f1c · required | local_keychain | not stored |
| RUNBOOK_API_KEYsb_9a02 · required | local_env | not stored |
| TELEMETRY_TOKENsb_c7d5 · optional | local_env | not stored |
Compatibility is analysed against real host facts before any file is touched. Two servers would apply cleanly; one cannot resolve a required secret on this machine, so the plan holds rather than half-applying.
Compatible. Command resolves on this host; no secret bindings required.
Compatible. Header binding ISSUE_TRACKER_TOKEN resolves from the local keychain.
Blocking: RUNBOOK_API_KEY is not available on this device. Nothing is written.
Illustrative example — not live data
Discovery, packaging, and catalogs are a solved and crowded problem, and Zephr is not going to pretend otherwise. What is not solved is binding a connection to a project scope and keeping credentials as references on the machine that owns them. That is the only ground Fleet claims.
If you want the last one, the honest answer is that a simpler third-party tool will serve you better. Fleet is opinionated on purpose.
The profile domain and the adapters are real. The credential plane they ultimately depend on is not finished, and the live fleet view has no real data behind it — both are badged accordingly rather than mocked up.
A deterministic, canonically-serialized profile schema with a content hash, so two machines can agree byte-for-byte on what a connection is.
Claude Code, Cursor, and Codex config dialects are parsed and rendered through the adapter contract. opencode is on the same contract.
Bindings carry a name, a provider class, and a required flag. The value resolves on the enrolled device at connection time; the cloud stores the reference and the audit event.
Platform, executable availability, and secret availability are checked against real host facts, producing a plan with blocking and advisory issues before any write.
Every listed adapter must pass the contract suite before it appears in Fleet. General availability of that gate is still moving.
The credential plane the profile lifecycle depends on is specified and not yet complete. Until it lands, Fleet does not claim managed device identity.
Real connection telemetry does not exist yet, so the Fleet surface shows an honest empty state instead of a dashboard of machines that are not there.
Fleet does not compete with bundle formats, catalogs, or the official registry. It may consume those formats; it will not reimplement discovery, packaging, or curation.
Fleet is easiest to trust once you have seen a profile round-trip without a single secret value leaving the machine.