Deploy and operate
How Hypervibe is planned to run for one person or a team, how people and machines join, and who may perform each sensitive operation.
On this page
This page is for whoever runs Hypervibe, alone or for a team: where each part runs, who may change what, and how updates and restores keep work safe.
One personal machine or one team server covers the first release #
| Setup | What runs there | How it signs in or joins | Where its records live |
|---|---|---|---|
| Just me | Rocket!, Throttle and a managed GraphLake engine for one person, on one Linux x86-64 machine | No sign-in: the operating-system user who installed it is the owner, and other users are refused | An encrypted database on that machine |
| Team server | The Hypervibe service, the platform's system of record, Throttle and the team's managed GraphLake engine, on a Linux server the team hosts | Members sign in with Google after an invitation | PostgreSQL on the server |
| Team member's machine | Rocket! for one member, with inference through the team server | The member's own sign-in, which Throttle holds | Team records cached by revision; personal records stay on the machine |
| Build or agent machine | Build and verification jobs that Reactor admits for the team | An enrollment code issued by an owner or admin | Reports what it observes to the team server |
Each machine keeps everything Hypervibe stores in one folder: ~/.hyper/ for a person, or the same layout under a dedicated system user on a server. No file there is edited by hand; settings are records with an owner, a scope and a revision. A server hosted by Hypervibe is Planned as a later packaging profile, and a shared multi-replica service is deferred. Unavailable macOS and Windows are not part of the first release, and the phone companion comes after it.
People and machines join without passwords #
A member joins by invitation, including people from outside the team's own domain, and signs in with Google. There are no passwords and no emailed sign-in links. A machine without a browser uses a device code: you open a fixed address and type the code, which never travels inside a link.
A machine joins with an enrollment code and gets its own machine identity. A person's sign-in is never copied to it, and enrollment alone grants nothing. A disconnected machine continues only within the grants, leases and budget it already holds, and never becomes an authority. Organizations are isolated, and personal records never reach the team server.
Team server setup is planned as checked steps: configuration with no secret written into it, store migrations with backup evidence, a check of database roles, then a backup and a restore rehearsal. Going live is refused until that restore passes.
Each sensitive action has a named role #
Organization roles are owner, admin and member; workspace roles, which govern what you may do to a lane, are owner, operator, viewer and guest. Owner and admin below are organization roles.
| Action | Who may do it | Safeguard |
|---|---|---|
| Run the team server | Owner or admin | Going live waits for a passing restore rehearsal |
| Invite a person | Owner or admin | Joining needs the invitation and a Google sign-in |
| Issue a machine enrollment code | Owner or admin | The machine gets its own identity, never a person's |
| Change team settings and budgets | Owner or admin | Each write names the revision it read; a stale write is refused |
| Issue grant, Revoke grant | Owner or admin | Checked at search, at resolve and at every use |
| Pause or revoke a device, remove a member, revoke a machine | Owner or admin | Requests, inference and attachment are required to be refused within 60 seconds |
| Approve a package for the team | The team's policy owner | A person activates anything new or wider |
| Request a change to Throttle's economics policy | Fleet's agents, under a grant, in a later release | A typed request that applies only when it is approved, with an audit record; Throttle never changes its own policy unprompted |
Fleet, the privileged operations workspace, acts only under explicit grants that can be revoked. Each of its actions leaves an audited receipt, and it cannot approve a wider authority for itself. Package approval and Fleet's tools are planned for later releases.
Grants are checked where the effect happens #
A grant gives one capability, at one scope, to one subject, such as a person, an agent, a team or a workspace. Team membership is read when a grant is checked, never copied into it, and "not found" and "not visible" are the same answer.
Throttle holds every credential value. The one secret it never holds or lends is the key that encrypts the platform's own store on a machine, which stays in a key file only its owner can read or in the operating system's keychain. Hypervibe keeps only a secret reference with its type, scope, owner and grants, and no screen shows a value. A process receives a credential only as a temporary lease. Revocation stops future delivery; where a value already delivered still needs rotating at its source, Hypervibe says so. The first release puts inference credentials in Throttle's custody, and the remaining credentials follow in a later release.
Updates and restores never undo settled work #
Backups are checked by restoring them, and on Just me the backup is taken online and stays encrypted. A restore starts a new generation of the store, and clients resume from it by revision. Restoring does not reverse settled usage, revoke credentials already issued or erase accepted work.
Reactor owns installation. Each installation has exactly one updater, and live work holds an update until it ends. If a new release fails its check, the previous one returns only when every store can still be read by it; otherwise the release is held for a forward repair, and a release you rolled back from is never selected again automatically. Parts run at different versions only in combinations qualified together. Background updates are planned for a later release.
Route names, media types, refusal codes and schema identifiers keep their values, and a breaking change gets a new version. A later release plans to move settings and state from earlier installs of Throttle, Lanes or BuildCTL, Reactor's predecessor, once, with a receipt, when Hypervibe replaces that tool; the old folder stays as a backup. The planned hyper uninstall deletes stored data only when you explicitly ask it to purge.
Diagnostics report identifiers and outcomes, never content #
The planned hyper doctor compares desired, installed, observed and usable state for each part of an installation, applies nothing and proposes repairs as plans. A remote fact that cannot be read fresh shows as stale with its age, and unknown is never shown as healthy. Logs carry identifiers and outcomes only, and on a team each inference request records the person, machine, team and lane.
Where to go next #
- Choose a profile to see which setup fits you.
- Install for what setup, updates and removal are designed to change on a machine.
- Hypervibe platform for identity, grants and configuration.
- Fleet for machines, placement and repair.
- Throttle for credential custody and team usage.
- Troubleshoot for refusals and how to read them.