Edge & fleet management
The edge is the deployment System9 is built for, sovereign, air-gapped, on-premises, on the device, so the machinery that gets code onto a fleet and keeps a device reachable in a hostile network is a first-class part of the platform, not an afterthought. This page covers two halves of that: how a single Edge Agent reaches a cell across whatever network it has, and how the core drives releases across a whole fleet.
The transport ladder
The Edge Agent composes its carriers into one transport stack with priority failover and health tracking. gRPC is primary; each other leg mounts as a fallback only when the operator has configured it, in a fixed preference order, richer carriers before more constrained ones, encrypted DNS last. If an adversary blocks one protocol, the agent fails over to the next healthy leg without a network redesign.
Figure B5: the carrier ladder. gRPC is the primary leg (green); five
fallback legs mount in preference order below it, each opt-in per device. The
detached, dashed node is air-gapped bundle carriage, deliberately outside
the ladder, because it is a mode that replaces the transport stack, not an
automatic failover leg (a store-and-forward acknowledgement must never let an
outage read as success). Ceiling: radio is a declared transport kind with no
driver and is not a carrier; each leg is opt-in per device, and a half-filled
config block mounts nothing; the client wire contract is covered by mock-gateway
tests, with end-to-end validation against a live backend pending.
Table equivalent
| Carrier | Position | Survives | Notes |
|---|---|---|---|
| gRPC | primary | standard connected sites | full-duplex; token streaming |
| HTTPS REST | fallback 1 | ordinary HTTP egress | |
| WebSocket | fallback 2 | long-lived duplex over HTTP | |
| SSH tunnel | fallback 3 | bastion-only estates | |
| MQTT | fallback 4 | constrained / IoT / cellular | refuses to publish a query in the clear with no sealing key |
| DNS-over-HTTPS | fallback 5 (last) | censored networks | heartbeat-class only |
| Air-gapped bundles | outside the ladder | fully disconnected sites | a mode that replaces the stack; never an automatic failover leg |
Why air-gap is outside the ladder
Air-gapped operation is a mode checked before anything dials, not a leg the stack falls through to. With a bundle directory configured, the agent writes signed bundles to disk for an operator to carry to the cell, and builds no network leg at all. Calls that need the cell's answer inside the same call, enrollment, command polling, certificate refresh, delegation rotation, revocation checks, refuse rather than returning a synthetic success, and the acknowledgements that are returned say plainly that the bytes are queued for carriage and verified at ingest. Nothing claims work the cell has not done. In the strictest posture, where nothing may leave the device at all, the agent runs a resident local daemon that owns everything needing no cell, the signed, hash-chained journal, on-device model serving, local working storage, and observes its certificate's remaining life (warning inside a courier window) rather than renewing it.
Fleet management from the core
The other half is driving a fleet from the core. Releases move by signed packages and manifests through release tracks, targeted at named cohorts, and rolled out ring by ring under a rollout state machine, so a change reaches a canary ring before it reaches the fleet, and its progress is a controlled state rather than a push-and-pray.
Figure: fleet rollout. A signed package and manifest flow through a release track and advance ring by ring (cyan rings are in-flight; the full-fleet ring is green when converged), with drift detection reconciling desired versus actual state on each device.
Table equivalent
| Concept | What it is |
|---|---|
| Signed package + manifest | The release artifact and its manifest, cryptographically signed |
| Release track | The channel a package is published on |
| Named cohort | A named target set of devices |
| Ring-by-ring rollout | A state machine that advances the release from a canary ring outward to the full fleet |
| Drift detection | Continuous desired-versus-actual reconciliation per device |
| Install tokens · GitOps reconciliation | Gated installation and declarative reconciliation of fleet state |
| 40+ device records | Battery, storage, location, transport health, certificate status and pending commands, refreshed on every heartbeat, with stale-device detection at two thresholds |
This section is the shape. Fleet Releases is the mechanism: post-quantum signed packages and the transparency log, cohorts defined as queries rather than lists, the ring state machine with health gates and automatic rollback, freeze and blackout windows, drift severity, and declarative GitOps, with the owed slices named.
Governed by the same plane as everything else
The edge is not a bolt-on management console. Edge telemetry correlates with the rest of the estate in one detection engine and one response playbook, response automation can suspend a device, revoke its delegation, or push a zeroize command. Governed egress applies too: one cell per organization and traffic class is elected to own the outbound connection, and edge model queries are brokered with classification, compartment and data-grant enforcement on every call. And the principle holds throughout: the edge is observed and governed, never billed as core consumption.
The most restricted deployments run a licensed tactical profile, feature-gated behind a signed licence that binds operation to a specific customer, jurisdiction, device set and time window, with compiled-in protected-classification red lines that no operator, policy, or software update can override.
In the console
An operator drives all of this from the Fleet console, a tree under
/core/fleet in the Core System console: the main page carries the rollout,
drift, peer-relay, sneakernet, package, and cohort views, with Devices
(/core/fleet/devices), Fleet topology (/core/fleet/topology), Install
tokens (/core/fleet/install-tokens), Brought online
(/core/fleet/brought-online), and edge policy and policy bundles as
sibling routes. These surfaces self-gate on the backend's system.fleet.*
capability namespace, for example issuing an install token requires
system.fleet.deploy.write, and reading edge policy requires
system.fleet.policy.read. Rollout lifecycle actions (start, pause, resume,
cancel, roll back, and a signed override of the health/drift gate) live on the
Rollouts tab. The full surface, its capability map and its roadmap slices are in Config deployment.
Related topics
-
Fleet Releases, the release mechanism in full: signing, cohorts, rings, gates, rollback and GitOps.
-
Administration & Configuration, the operator surfaces and how config deploys.
-
Core and edge, what the Edge Agent is, and how a cell deployed at the site turns the edge into a full sovereign stack.
-
Deployment topology, where the edge sits among the deployment shapes, and its offline supply paths.
-
Data residency, the residency constraint governed egress resolves against.