Fleet
How Fleet, Hypervibe's privileged operations workspace, will manage machines, capacity, rollout and repair under revocable grants, without a store or scheduler of its own.
On this page
Fleet is Hypervibe's privileged operations workspace. Its agents look after the machines and capacity underneath your work: they enroll machines, provision and release capacity, roll out and repair services, and retire what is no longer needed. This page explains where Fleet's actions land and what limits them.
Fleet acts through other owners and keeps no store of its own #
Fleet is a built-in Lanes workspace template. Its agents carry a set of operator tools under explicit, revocable grants recorded in the policy of the Hypervibe service, the platform's system of record. Fleet keeps no store of its own and adds no scheduler. Each action lands with the owner that applies it, and each leaves an audited receipt.
| Fleet action | Lands as | Applied by |
|---|---|---|
| Enroll, cordon or retire a machine | An inventory record | The Hypervibe service, which keeps the inventory |
| Change budgets or other economics policy | A policy request that needs approval | Throttle |
| Provision capacity, or repair or retire a service | A job | Reactor |
| Rotate a secret | A rotation recorded by the Hypervibe service | Throttle, which holds the value |
| Promote or retire a package | A registry change that uses a verdict as evidence | The Hypervibe service |
A verdict alone grants nothing: promotion is its own authorized operation. Each workspace names one coordinator lane. A need that a lane cannot settle travels to its coordinator, then to the fleet admin, the one lane through which Fleet's policy speaks.
Machines are registered before they are used #
The Hypervibe service keeps the inventory: machines, virtual machines, workers, browser pools and deploy targets, each with its identity, parent, capacity, qualification and health. A host name is an attribute, never the identity, and no record holds a credential. Discovery only proposes; an unrecognized machine is never changed automatically.
Each machine's inventory state is one of observed, enrolled, qualified, cordoned, draining, offline or retired, and every change between them is an explicit transition. An enrolled machine also has a machine standing: its current permission to take work. This is not the standing that each page of these docs shows. Registration is not admission, so a registered machine can still be unusable.
A machine team groups machines with eligibility and reservation rules. It is not a team of people and not an agent team. Enrollment, membership and a machine team's capacity are separate records.
Capacity follows goals within bounds approved in advance #
You name goals and requirements, not virtual machines. Fleet chooses qualified capacity that already exists, provisions more when justified and releases what sits idle. Machine capacity is Fleet's concern; inference usage and economics are Throttle's.
Bounds approved in advance limit the accounts, regions, resource classes, network exposure, spend and destructive actions Fleet may use, and Fleet cannot raise its own limits. When a capability is missing or a limit is exhausted, Fleet records a blocked state or a request. It never falls back to a broader account, weaker isolation or whatever credentials happen to be available. Fleet keeps the placement and rollout policy, within what central governance authorizes, and Reactor makes each placement within it.
Rollout and repair change desired state, not live machines #
Repairs change source or desired state; hand-editing a live machine is not how Hypervibe operates. Known drift is reconciled with bounded retries and an action budget. A novel failure can start a diagnostic workflow that proposes a versioned repair; its agent cannot silently edit the live machine or widen its own authority.
A service upgrade stages a verified artifact, preserves data, runs a canary and moves traffic only on evidence. Rolling back Fleet's policy does not restore revoked grants or reverse settled money. When a create, deploy or delete has an unknown outcome, the original operation is observed, never sent again blindly. A process exit, a finished build, a deployment, a ready endpoint and an accepted outcome stay five different facts.
Grants bound Fleet, and revocation fences #
Central governance sets the policy and limits that Fleet works under, and Fleet cannot approve a wider authority for itself. Custody of secrets and the signing of grants are protected from ordinary Fleet administration. Installing a connector or enrolling a machine issues no grant.
A machine that loses its connection continues only work it was already authorized for, within live grants, budget and freshness bounds; it never gains authority. Revoking a machine's standing fences it, so the next dispatch to it is refused. In the first release, before Fleet runs on Hypervibe, a team administrator enrolls machines and revokes their standing, and the team record, the evidence that a whole run works for a team, requires that refusal within 60 seconds. Fleet's tools take over the same enrollment step in a later release.
Health and retirement need evidence #
Health and the freshness of what a machine reports are separate facts. A machine that disappears is marked lost and keeps its allocations until the outcome is established. Cordon stops new placement. Drain respects active leases, persistent volumes, uncommitted changes and service commitments.
Retirement needs an inventory of what still uses or holds the machine, and a release receipt. Teardown drains dependents, meets retention, revokes grants, removes resources in dependency order, then checks that they are gone and that billing stopped. An accepted delete request is not enough. Possible orphans are listed, never adopted or deleted automatically.
Where to go next #
- Reactor for jobs, placement and registered workers.
- Throttle for inference capacity and economics policy.
- Lanes for the workspace Fleet runs in.
- Deploy and operate for enrollment and revocation.