Compute substrate
topic(systems): infrastructure-os + os-network-admin — PPN substrate, Genesis Protocol, F8 control plane
@@ -1,43 +1,73 @@ --- schema: foundry-doc-v1 title: "Infrastructure OS" title: "os-infrastructure — The Compute Substrate" slug: infrastructure-os category: systems type: topic type: concept quality: complete short_description: "Infrastructure OS is the virtualization layer and private network engine that hosts and coordinates multiple Totebox Archives across on-premise and cloud environments." status: active audience: vendor-public bcsc_class: public-disclosure-safe last_edited: 2026-05-04 language_protocol: PROSE-TOPIC last_edited: 2026-05-15 editor: pointsav-engineering 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." 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 (PPN): an encrypted WireGuard mesh that ties Toteboxes, Consoles, MediaKits, and PrivateGit instances together without exposing any node to the public internet. This article covers the three deployment postures, the Genesis Protocol that bootstraps a fleet, and the structural gap in conventional cloud offerings that the design exploits. **Infrastructure OS** is the virtualization and networking backbone of the PointSav ecosystem. It operates as the foundational host layer that permits the execution of multiple isolated Totebox Archive instances on a single physical or virtual machine. ## The three deployment postures ## Virtualization and Orchestration `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: The primary role of **Infrastructure OS** is to virtualize hardware resources for the PointSav substrate. It acts as the underlying host for the **Micro Virtual Machines** that run individual Toteboxes. | 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-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 | Through its integration with [[topic-totebox-orchestration]], Infrastructure OS manages the lifecycle of these archives, ensuring they remain isolated at the kernel level while providing the necessary compute resources for their internal services (such as extraction, indexing, and search). 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. ## PointSav Private Network ## The Genesis Protocol Infrastructure OS creates and maintains the **PointSav Private Network**. This is an encrypted, peer-to-peer overlay network that permits secure communication between distributed PointSav appliances. 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. Every node running Infrastructure OS becomes a verified member of this network, allowing for: * **Encrypted Data Transfer:** Moving Totebox Archive bootable images between locations safely. * **Linguistic Signaling:** Coordinating task execution across clusters without exposing raw data to the public internet. * **Remote Administration:** Enabling secure access via [[topic-console-os]]. 1. **Blind boot.** The node ignores DHCP and DNS conventions. The 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. 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. 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. ## Hybrid Deployment 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. Infrastructure OS is designed for **Hybrid Deployment**. It can boot directly on Bare metal resources for maximum performance and security on-premise, or it can be deployed on public cloud resources (such as GCP, AWS, or Azure) to provide scalable infrastructure while maintaining the same sovereign security protocols. ## The PointSav Private Network ## See Also Every `os-infrastructure` node is a member of the PPN — the WireGuard overlay that connects all PointSav appliances in a fleet: - [[topic-totebox-os]] - [[topic-totebox-orchestration]] - [[topic-totebox-archive]] - [[topic-network-admin-os]] - Encrypted data transfer: Totebox archive images move between locations without touching the public internet. - Linguistic signalling: `os-network-admin` broadcasts 16-byte binary commands across the 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. ## The Hyperscaler Gap The architecture deliberately exploits a structural gap in conventional cloud offerings: | 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 | | 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 | | 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 fiduciary key. ## See also - [[os-network-admin]] — the control plane that commands `os-infrastructure` fleets - [[os-family-overview]] — the full eight-OS family and how each member fits - [[totebox-os]] — the archive OS hosted on `os-infrastructure` nodes - [[diode-standard]] — the protocol that governs command flow between nodes - [[machine-based-auth]] — how fiduciary keypairs and pairings secure fleet membership - [[deployment-patterns]] — the six canonical fleet configurations