Skip to content

Diff: systems/infrastructure-os

From 3cbe592 to 3cbe592

+0 / −0 lines
BeforeAfter
--- ---
schema: foundry-doc-v1 schema: foundry-doc-v1
title: "Compute substrate" title: "Compute substrate"
slug: infrastructure-os slug: infrastructure-os
category: systems category: systems
type: concept type: concept
quality: complete quality: complete
status: active status: active
audience: vendor-public audience: vendor-public
bcsc_class: public-disclosure-safe bcsc_class: public-disclosure-safe
language_protocol: PROSE-TOPIC language_protocol: PROSE-TOPIC
last_edited: 2026-05-15 last_edited: 2026-05-15
editor: pointsav-engineering editor: pointsav-engineering
paired_with: infrastructure-os.es.md paired_with: infrastructure-os.es.md
short_description: "os-infrastructure is the compute substrate that hosts PointSav operating systems across on-premises, leased, and cloud hardware. It creates the PointSav Private Network and bootstraps isolated fleets through the Genesis Protocol." short_description: "os-infrastructure is the compute substrate that hosts PointSav operating systems across on-premises, leased, and cloud hardware. It creates the PointSav Private Network and bootstraps isolated fleets through the Genesis Protocol."
cites: [] cites: []
--- ---
`os-infrastructure` is the compute substrate that hosts the other PointSav operating systems. One instance runs on one piece of hardware — a bare-metal server in an office, a colocated rack, or a cloud virtual machine. Taken together, a fleet of `os-infrastructure` nodes forms the [[pointsav-private-network|PointSav Private Network]] (PPN): an encrypted WireGuard mesh that ties [[totebox-os|Toteboxes]], [[console-os|Consoles]], [[mediakit-os|MediaKits]], and [[os-privategit|PrivateGit]] instances together without exposing any node to the public internet. This article covers the three deployment postures, the [[genesis-protocol|Genesis Protocol]] that bootstraps a fleet, and the structural gap in conventional cloud offerings that the design exploits. `os-infrastructure` is the compute substrate that hosts the other PointSav operating systems. One instance runs on one piece of hardware — a bare-metal server in an office, a colocated rack, or a cloud virtual machine. Taken together, a fleet of `os-infrastructure` nodes forms the [[pointsav-private-network|PointSav Private Network]] (PPN): an encrypted WireGuard mesh that ties [[totebox-os|Toteboxes]], [[console-os|Consoles]], [[mediakit-os|MediaKits]], and [[os-privategit|PrivateGit]] instances together without exposing any node to the public internet. This article covers the three deployment postures, the [[genesis-protocol|Genesis Protocol]] that bootstraps a fleet, and the structural gap in conventional cloud offerings that the design exploits.
## The three deployment postures ## The three deployment postures
`os-infrastructure` is the same OS in three postures. The operator chooses where their compute lives — and can blend any combination in a single fleet: `os-infrastructure` is the same OS in three postures. The operator chooses where their compute lives — and can blend any combination in a single fleet:
| App surface | Hardware | Trust profile | | App surface | Hardware | Trust profile |
|---|---|---| |---|---|---|
| `app-infrastructure-onprem` | Servers on the operator's own premises | Highest trust; the operator owns and can physically verify the hardware | | `app-infrastructure-onprem` | Servers on the operator's own premises | Highest trust; the operator owns and can physically verify the hardware |
| `app-infrastructure-leased` | Colocated bare-metal at an external data centre | Hybrid trust; the operator controls the OS but cannot physically verify every boot | | `app-infrastructure-leased` | Colocated bare-metal at an external data centre | Hybrid trust; the operator controls the OS but cannot physically verify every boot |
| `app-infrastructure-cloud` | Hyperscaler VMs (GCP, AWS, Azure) | Lowest trust; used for stateless edge relay, not persistent storage | | `app-infrastructure-cloud` | Hyperscaler VMs (GCP, AWS, Azure) | Lowest trust; used for stateless edge relay, not persistent storage |
The same WireGuard mesh runs across all three. An operator can start with a single cloud relay and add on-premises nodes later without restructuring software. The same WireGuard mesh runs across all three. An operator can start with a single cloud relay and add on-premises nodes later without restructuring software.
## The Genesis Protocol ## The Genesis Protocol
Conventional fleet management requires a control plane to exist before any compute node can join. `os-infrastructure` inverts this. When a node boots and finds no PPN beacon, it does not fail — it declares itself a Private Network of One. Conventional fleet management requires a control plane to exist before any compute node can join. `os-infrastructure` inverts this. When a node boots and finds no PPN beacon, it does not fail — it declares itself a Private Network of One.
1. **Blind boot.** The node ignores DHCP and DNS conventions. The [[sel4-microkernel-substrate|seL4]] kernel generates a Tier-1 fiduciary keypair at first boot. 1. **Blind boot.** The node ignores DHCP and DNS conventions. The [[sel4-microkernel-substrate|seL4]] kernel generates a Tier-1 fiduciary keypair at first boot.
2. **Scan.** The node looks for an `os-network-admin` beacon on the local mesh. 2. **Scan.** The node looks for an `os-network-admin` beacon on the local mesh.
3. **Genesis fork.** If nothing answers, the node creates its own one-node PPN and seals all external ports except one. 3. **Genesis fork.** If nothing answers, the node creates its own one-node PPN and seals all external ports except one.
4. **Holding pattern.** A single hardened WebSocket endpoint waits for an administrative claim. 4. **Holding pattern.** A single hardened WebSocket endpoint waits for an administrative claim.
5. **Claim.** When an administrator boots `os-network-admin` and presents the administrative fiduciary key, the node verifies the claim, binds to the fleet, and joins the mesh. 5. **Claim.** When an administrator boots `os-network-admin` and presents the administrative fiduciary key, the node verifies the claim, binds to the fleet, and joins the mesh.
A customer can ship fifty servers to fifty edge locations. Each boots, forms a single-node PPN, and holds. Whenever the administrator is ready, the central `os-network-admin` claims all of them, merging them into one global fleet. The nodes do not need to know in advance how many siblings they will eventually have. A customer can ship fifty servers to fifty edge locations. Each boots, forms a single-node PPN, and holds. Whenever the administrator is ready, the central `os-network-admin` claims all of them, merging them into one global fleet. The nodes do not need to know in advance how many siblings they will eventually have.
## The PointSav Private Network ## The PointSav Private Network
Every `os-infrastructure` node is a member of the PPN — the WireGuard overlay that connects all PointSav appliances in a fleet: Every `os-infrastructure` node is a member of the PPN — the WireGuard overlay that connects all PointSav appliances in a fleet:
- Encrypted data transfer: [[totebox-archive|Totebox archive]] images move between locations without touching the public internet. - Encrypted data transfer: [[totebox-archive|Totebox archive]] images move between locations without touching the public internet.
- Linguistic signalling: `os-network-admin` broadcasts 16-byte binary commands across the [[sovereign-mesh|mesh]]; every node receives simultaneously, only the addressed node acts. - Linguistic signalling: `os-network-admin` broadcasts 16-byte binary commands across the [[sovereign-mesh|mesh]]; every node receives simultaneously, only the addressed node acts.
- Remote administration: `os-console` pairs to `os-totebox` instances through the PPN without requiring a VPN client on the operator's host machine. - Remote administration: `os-console` pairs to `os-totebox` instances through the PPN without requiring a VPN client on the operator's host machine.
## The Hyperscaler Gap ## The Hyperscaler Gap
The architecture deliberately exploits a structural gap in conventional cloud offerings: The architecture deliberately exploits a structural gap in conventional cloud offerings:
| Conventional cloud | os-infrastructure | | Conventional cloud | os-infrastructure |
|---|---| |---|---|
| Couples compute to proprietary storage; charges egress for data movement | Treats the cloud as a stateless relay; persistent storage stays on the operator's hardware | | Couples compute to proprietary storage; charges egress for data movement | Treats the cloud as a stateless relay; persistent storage stays on the operator's hardware |
| Provides rental access; withholds custodial ownership | The operator can physically unplug and move the substrate | | Provides rental access; withholds custodial ownership | The operator can physically unplug and move the substrate |
| Requires network engineering before compute can be added | Nodes self-bootstrap via the Genesis Protocol | | Requires network engineering before compute can be added | Nodes self-bootstrap via the Genesis Protocol |
| Single-vendor control plane as a single point of failure | Every `os-infrastructure` node can genesis a fleet independently | | Single-vendor control plane as a single point of failure | Every `os-infrastructure` node can genesis a fleet independently |
An operator running `os-infrastructure` on a single server in their office, a cloud relay node for public connectivity, and `os-network-admin` on an administrative workstation has built a fleet that is not locked to any hyperscaler and is inaccessible to external attackers without a valid [[machine-based-auth|fiduciary key]]. The [[storage|storage architecture]] for each node follows the [[worm-ledger-design|WORM discipline]] that governs all PointSav data persistence. An operator running `os-infrastructure` on a single server in their office, a cloud relay node for public connectivity, and `os-network-admin` on an administrative workstation has built a fleet that is not locked to any hyperscaler and is inaccessible to external attackers without a valid [[machine-based-auth|fiduciary key]]. The [[storage|storage architecture]] for each node follows the [[worm-ledger-design|WORM discipline]] that governs all PointSav data persistence.
## See also ## See also
- [[os-network-admin]] — the control plane that commands `os-infrastructure` fleets - [[os-network-admin]] — the control plane that commands `os-infrastructure` fleets
- [[os-family-overview]] — the full eight-OS family and how each member fits - [[os-family-overview]] — the full eight-OS family and how each member fits
- [[totebox-os]] — the archive OS hosted on `os-infrastructure` nodes - [[totebox-os]] — the archive OS hosted on `os-infrastructure` nodes
- [[diode-standard]] — the protocol that governs command flow between nodes - [[diode-standard]] — the protocol that governs command flow between nodes
- [[machine-based-auth]] — how fiduciary keypairs and pairings secure fleet membership - [[machine-based-auth]] — how fiduciary keypairs and pairings secure fleet membership
- [[deployment-patterns]] — the six canonical fleet configurations - [[deployment-patterns]] — the six canonical fleet configurations