- Rust 66.9%
- Nix 17.6%
- JavaScript 6.1%
- TypeScript 4.3%
- CSS 3.5%
- Other 1.6%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
The read policy and cert-auth role for each hive were written once, at startup. On the deploy that surfaced this, the store was still coming up, the pass logged its warning and moved on, and no hive could log in until someone restarted the daemon — while cert auth answered "no chain matching all constraints", which reads like a certificate problem rather than a role that was never created. The bootstrap unit in swarm-bao.nix lost the same race and won on its retry 30s later. A daemon that boots alongside its store loses that race routinely; on a normal boot it is the ordinary case. The two passes fold into one `provision()` that logs in once instead of twice for two loops over the same list, keeping policy before role since the role names the policy. `ensure_hive_access` still awaits the first pass, so a store that is already up leaves nothing deferred, and only a pass that could not reach the store at all spawns the retry. The retry is `config_pr::spawn`'s idiom from this same crate: an interval task whose first tick is immediate. Its cadence and bound match the bootstrap unit's — 30s, ~a day — because the two halves of one race should not disagree about how long a wait is worth. `Error::MissingEnv` is what keeps it from spinning forever: no `BAO_*` set means a deployment that runs no store, where asking again changes nothing, so it returns Ok. Everything else is retryable, including an authority file that is not placed yet — the unit that writes it starts alongside this one. Both cases previously landed in the same "not managed here" line, so a store that was late looked exactly like one that was never configured. Per-hive failures keep their old behaviour: logged, skipped, Ok. A store that refuses one hive's write refuses it again, so the next start really is the right retry for those, and the module doc still says so. Closes #4176. |
||
| .forgejo/workflows | ||
| branding | ||
| claude-plugins | ||
| docs | ||
| frontend | ||
| hive-agent | ||
| hive-agent-mcp | ||
| hive-agent-sock | ||
| hive-bash-mcp | ||
| hive-c0re | ||
| hive-core-agent-sock | ||
| hive-forge | ||
| hive-forge-notify | ||
| hive-host-sock | ||
| hive-jobq | ||
| hive-jobq-metrics | ||
| hive-jobq-wire | ||
| hive-matrix-mcp | ||
| hive-metric | ||
| hive-priv | ||
| hive-priv-sock | ||
| hive-screen-mcp | ||
| hive-sh4re | ||
| hive-sock-client | ||
| hive-subagent-mcp | ||
| hive-types | ||
| hivectl | ||
| nix | ||
| scripts | ||
| swagger-ui-theme | ||
| swarm-authelia-bridge | ||
| swarm-authelia-bridge-sock | ||
| swarm-controller | ||
| swarm-nats-auth | ||
| swarm-queue-client | ||
| swarm-secret-client | ||
| swarmctl | ||
| .gitignore | ||
| .mailmap | ||
| .prettierignore | ||
| .prettierrc | ||
| .vale.ini | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CLAUDE.md | ||
| clippy.toml | ||
| flake.lock | ||
| flake.nix | ||
| README.md | ||
hyperhive
a swarm of claude-code agents, each in its own nspawn cage, gossiping over unix sockets. config changes flow as git commits, the operator approves them in a browser, every deploy is a tag. cyberpunk-themed dashboard included. 💜⚡
Claude code is great in one window, exponentielle across many — but only if you can keep the agents from stepping on each other, give them durable identity, and stop them from eating production. hyperhive is the substrate.
- identity = unix socket
- communication = sqlite-backed broker (
send/recv/remind) - config = git (manager proposes, operator approves, deploys land as tagged commits)
- blast radius = container
every hive (NixOS host, runs hive-c0re.service)
│
├── operator
│ ├── browser → :80 (hive-gateway) dashboard + per-agent UIs
│ │ /agent/<name>/ → per-agent unix socket
│ └── CLI → /run/hyperhive/host.sock admin protocol
│
├── hive-c0re (Rust daemon: lifecycle / broker / approvals /
│ auto-update / dashboard / sockets)
│
├── hive-gateway (optional) nginx — proxies :80 → c0re dashboard + per-agent sockets
│
└── agent containers
├── h-ruth manager (privileged MCP surface, approval gating)
└── h-<name> sub-agent (claude + MCP tools + per-agent web UI + unix socket)
one host per swarm (optional — connects hives; can be any hive, including
one that's also running the tree above)
│
├── hive-forge Forgejo — swarm-wide singleton, per-agent accounts + config mirror
├── hive-matrix tuwunel — swarm-wide singleton, Matrix homeserver + per-agent accounts
├── swarm-controller cross-hive state: hive directory, agent roster, jobs
├── swarm-ui swarm-wide SPA, served straight off the gateway (no own container)
├── swarm-authelia SSO — one login gates swarm-ui + Grafana + more
├── swarm-nats message queue (JetStream KV: hive-status, …)
├── swarm-otel telemetry collector, sole holder of the upstream credential
├── swarm-victoriametrics metrics store
├── swarm-victorialogs log store
└── swarm-grafana dashboards over the metrics/log stores, own OIDC login
→ website · → docs · → options reference
Depth lives in docs/ (rendered at
hyperhive.darkest.space/docs/) —
start at docs/README.md and pick the page matching
your task rather than reading front to back.
Quick start
Minimal flake.nix for a host that runs hive-c0re:
{
inputs = {
nixpkgs.url = "github:NixOS/nixpkgs/nixos-26.05";
hyperhive.url = "git+https://forge.darkest.space/hyperhive/hyperhive";
# Pin hyperhive to your own nixpkgs instead of the one it ships with
# (see "Overriding nixpkgs" below) — recommended for most hosts:
hyperhive.inputs.nixpkgs.follows = "nixpkgs";
};
outputs = { nixpkgs, hyperhive, ... }: {
nixosConfigurations.my-host = nixpkgs.lib.nixosSystem {
system = "x86_64-linux";
modules = [
hyperhive.nixosModules.default # hive-c0re + hive-forge + hive-gateway in one import
({ ... }: {
services.hyperhive.enable = true;
# services.hyperhive.c0re.operatorPronouns = "they/them"; # default: "she/her"
# ... rest of your host config
system.stateVersion = "25.11";
})
];
};
};
}
hive-c0re opens its admin socket + dashboard, auto-creates the
manager container, and auto-rebuilds any container whose hyperhive
rev goes stale. claude-code is unfree — hyperhive scopes the
whitelist to itself, nothing for the operator to set.
Overriding nixpkgs
hyperhive pins its own nixpkgs so it builds standalone in CI. Add
hyperhive.inputs.nixpkgs.follows = "nixpkgs" (as in the quick-start above)
to build it against your host's nixpkgs instead — one less nixpkgs
evaluation, no version drift from the rest of your system. Standard flake
follows pattern; works as long as your channel is reasonably close to the
nixos-26.05 hyperhive develops against. Drop it again if a much
older/newer channel hits breakage hyperhive's CI doesn't catch.
For the full list of host and agent NixOS options see the options reference.
Operator CLI
hivectl is the operator-facing host CLI for ad-hoc administration that
doesn't go through the broker (built alongside hive-c0re when the host
module is enabled):
sudo hivectl forge create-user mara # provisions a forge user
sudo hivectl forge create-user mara --password 'hunter2' # … with a fixed password
sudo hivectl matrix create-user mara # provisions a matrix user
sudo hivectl matrix create-user mara --password-stdin # … reading one line from stdin
For a name that's a managed agent, hivectl persists the resulting token
to that agent's state dir, the same as the boot sweep does. For a
non-agent name (e.g. the operator's own forge/matrix account), it prints
the token to stdout and writes nothing.
Build / deploy
nix develop -c cargo check
nix flake check # rust + nix + toml fmt + clippy
# deploy from a host config that imports hyperhive.nixosModules.default
nix flake update --update-input hyperhive
sudo nixos-rebuild switch --flake .#<host>