Hardware Manifest

Opplet Operations: Hardware Manifest

Version 1.2 · DRAFT (reconciles to Constitution v12.8) · Tier 3 · part of Charter Release 2026.3 · effective 2026-06-16

Purpose and Scope

This document records the current physical inventory and specifications of every node in the enclave. It is operational truth, not architectural law. Hardware refreshes update this document; they do not bump the Constitution.

The Constitution (§1 Hemispheric Strategy) mandates four physical nodes with specific roles. This Manifest specifies the actual machines fulfilling those roles right now.

Note on the Climb (v1.1): The Climb’s infrastructure now lands on the Outpost (§4). Those services are selected but not yet deployed — items marked (pending deployment) are planned allocations, not as-built state.

Note on the directories (v1.2): Both LDAP directories are hosted in the Basement (Zone 0); the prior Kitchen listing of LDAP-Beta is corrected (§2B, §8 #8).

1. The Den — Zone 1 (Sovereign Life)

The Den consists of two cloud VPSs, physically separated to isolate life-critical services from application workloads.

1A. Gateway VPS (“The Front Door”)

Role: Life-critical public services (email, telephony, control panel, reverse proxy). Traditionally managed; no Docker.

RAM allocation:

1B. Engine VPS (“The Workshop”)

Role: Personal applications, containerized via Docker.

RAM allocation:

1C. Den Networking

• Gateway and Engine connected via Tailscale private mesh.
• Engine has no public-facing ports; all traffic reverse-proxied through Gateway.
• No connectivity to any Hetzner enclave node (Constitution §5D Den Network Isolation).

1D. Den External Dependencies

2. The Manor — Zones 0, 2 (Sovereign Core)

Role: Business identity, internal automation, capital preservation, observability. High-availability cluster.

2A. Manor Cluster

Topology: Three-node Proxmox VE cluster with HA enabled.

Storage policy: Local ZFS replication on a 15-minute interval (SOP §5A) across the three nodes. No distributed storage spanning physical nodes (Constitution §5B Storage Isolation Mandate).

2B. RAM Allocation by Zone

Zone 0 (Basement) — total ~34 GB:

Both directories live in the Basement (Zone 0), served by Authentik-Business, even though LDAP-Beta governs the commons hosted outward across the Lounge (Zone 4) and the Range (Zone 5). A directory belongs in the most-protected zone; authentication reaches outward from there (Enclave Doctrine §2, §3; Software Stack §3A).

Zone 2 (Office) — total ~14 GB:

Combined Manor cluster utilization: ~48 GB allocated across 192 GB physical (3 × 64 GB). Comfortable headroom for HA failover (any single node can absorb the others’ workloads).

3. The Annex — Zones 3, 4 (Delivery Edge)

Role: Heavy I/O, CI/CD compilation, source code management, public/talent web traffic proxying.

3A. Annex Node

3B. RAM Allocation by Zone

Zone 3 (Kitchen) — total ~60 GB:

The Kitchen GitLab is the secret-bearing production forge (downstream of the free community forge via the one-way free→Kitchen mirror). It is distinct from the free community Forgejo that hosts the public, secret-free blueprints — that one lives on the Outpost (§4), not here. (LDAP-Beta no longer sits in this zone — relocated to the Basement in v1.2; see §2B, §8 #8.)

Zone 4 (Lounge) — total ~48 GB:

Combined Annex utilization: ~108 GB allocated across 128 GB physical (~84%). The LDAP-Beta relocation to the Manor (v1.2) eased this from ~88%, but it remains above the 75% headroom target in SOP §6; the first scheduled RAM Headroom Audit (October 2026) will assess whether rebalancing or upgrade is required.

4. The Outpost — Zone 5 (Live-Fire Range and the Climb)

Role: Host two network-isolated workloads on one node:

1. The live-fire range — vulnerable target VMs and defensible exploitation infrastructure.
2. The Climb’s infrastructure — the free community forge (Forgejo) and its CI (Forgejo Actions), the tracker (Vikunja), the four-face deploy grader, and the ephemeral practice forks (Incus system containers).

(Constitution §1–§2; Software Stack §5B.) The Climb’s durable datasets carry a backup exception (§5A; Constitution §5A/§9); the ephemeral practice forks are not backed up.

4A. Outpost Node

4B. RAM Allocation

Zone 5 (Range + the Climb) — total ~128 GB:

On the shared pool: the live-fire range targets and the Climb’s practice forks both draw from the same ~104 GB and are not guaranteed to be available concurrently. A fully loaded live-fire exercise and a full Climb cohort cannot both peak on this node at once. The always-on Climb services (~10 GB) are carved out permanently; everything else competes for the pool. At the SOP genesis cohort of 8–15 (forks are Incus system containers, ~2–3 GB each), a cohort fits comfortably when no large exercise is running. This concurrency limit and the node’s lack of headroom are tracked in §8.

5. Backup Infrastructure

5A. Proxmox Backup Server (PBS)

Location: The Manor (Zone 0). Role: Receives state pushes from the Annex per Constitution §5A Exception 3 and SOP §1A, and the Outpost’s durable Climb datasets (Forgejo repositories, Vikunja, curation records) under the Constitution §5A/§9 backup exception. Permissions: Drop-only from both the Annex and the Outpost; neither can read or delete existing backups. Note: The Outpost runs Incus rather than Proxmox VE, so its durable datasets reach PBS via ZFS send rather than native PVE→PBS integration. The ephemeral practice forks are excluded.

Specs: Allocated within the Manor cluster (RAM and storage drawn from the shared pool; not a separate physical node).

5B. External Watchdog

Location: Micro-VPS (separate provider from Hetzner, exact provider TBD). Role: Uptime Kuma monitoring per SOP §2. Specs: Smallest available tier sufficient to run Uptime Kuma — typically 1 vCPU, 1 GB RAM, 20 GB storage.

6. Network Topology

6A. Edge Router

OPNsense is virtualized on The Manor (Basement) per Constitution §5E. Single-instance with HA priority on the Manor cluster; SOP §4 defines resilience procedures.

6B. Hetzner vSwitch

The Manor, Annex, and Outpost are interconnected via Hetzner vSwitch (private layer-2 network). The Talent Proxy (Constitution §5C) routes through this network from the Annex Guacamole to the Outpost’s range targets and practice forks.

The Climb’s forge and tracker on the Outpost are reached differently — as ordinary Beta web services through Traefik (Authentik-walled for push; Constitution §5C, §7), not through the Air-Lock. The Air-Lock path is for interactive range/fork sessions; the forge and tracker are read-visible web apps.

6C. Den Isolation

The Den (Gateway and Engine VPSs) is on entirely separate Hetzner Cloud infrastructure with no connectivity to the vSwitch above. See Constitution §5D and the Den Migration Project document for network isolation enforcement.

7. Hypervisor Standard

The Manor and Annex run Proxmox VE on Debian. The Outpost runs Incus on Debian — chosen for the Climb’s ephemeral-fork workload (Software Stack §1, §5B) and recorded here as the deliberate exception to the otherwise-uniform Proxmox baseline. The Den VPSs run Ubuntu Server directly (no nested hypervisor — Docker on the Engine, native services on the Gateway).

Specific Proxmox versions, the Incus release, and Debian releases are tracked in the Software Stack Manifest.

8. Open Questions for Future Refresh

1. Manor cluster storage: Specific NVMe model and capacity per Manor node not yet captured. Add when next hardware audit confirms current state.
2. External Watchdog provider: Selection pending. Should not be Hetzner to maintain external observation.
3. SIP Trunk provider: Telnyx vs. JMP.chat selection pending (see Den Migration Project).
4. Annex RAM pressure: Combined allocation eased to ~84% of physical (from ~88%) by relocating LDAP-Beta to the Manor (v1.2) — still above the 75% target. Plan for either workload rebalancing, vertical upgrade (256 GB), or workload migration to a future second Annex node.
5. Outpost CPU age: AMD Ryzen 9 3900 is auction hardware. Replacement plan should exist before failure becomes likely — more pressing now that the node also carries the Climb (see #6).
6. Outpost is now dual-purpose. It hosts both the live-fire range and the Climb (forge, CI, tracker, deploy grader, practice forks). RAM is fully committed with no headroom, and a full live-fire exercise cannot run concurrently with a full Climb cohort (§4B). Resolve by scheduling the two apart, or by giving the Climb its own node once cohorts and exercises grow — the latter also relieves the auction-hardware single-point risk in #5.
7. Climb stack pending deployment. The §4B Climb services and fork budget are selected (Software Stack §5B) but not yet stood up; replace the planned figures with real allocations once deployed.
8. LDAP-Beta placement — RESOLVED (v1.2). LDAP-Beta now sits in the Basement (Zone 0) alongside LDAP-Alpha (§2B), matching Enclave Doctrine §2 and Software Stack §3A: a directory belongs in the most-protected zone and authenticates outward to the Beta world (Lounge, Range). The prior Kitchen (Zone 3) grouping — a v1.0 artifact that conflated the directory’s host with the population it serves — is corrected, and its ~4 GB moved from the Annex to the Manor.

Changelog

v1.2 (2026-06-16) — LDAP-Beta placement resolved; reconcile to Constitution v12.8

• LDAP-Beta relocated to the Basement (Zone 0). Both directories now sit in the Manor’s Basement under Authentik-Business (§2B), matching Enclave Doctrine §2 and Software Stack §3A; removed from the Kitchen (§3B). Its ~4 GB moves from the Annex to the Manor — Basement total ~30→~34 GB, Kitchen ~64→~60 GB, combined Annex ~112→~108 GB (~88%→~84%). Closes the carried flag (§8 #8) and updates the Annex-pressure item (§8 #4).
• Keystone references made version-agnostic — Constitution section refs no longer pinned to v12.5 (§4, §5A, §6B). Status reconciles to v12.8; returns to RATIFIED with the v12.6–v12.8 cluster.

v1.1 (2026-06-15)

• The Outpost is now dual-purpose. The Climb’s infrastructure (Forgejo, Forgejo Actions, Vikunja, the four-face deploy grader, and Incus practice forks) joins the live-fire range on it, following the v12.5 reversion of the forge to the Range (Constitution v12.5 §1–§2; Software Stack §5B). §4 retitled; role expanded; §4B re-allocated as a shared execution pool with the Climb’s always-on services carved out.
• Outpost hypervisor recorded as Incus (§4A, §7) — the deliberate exception to the Proxmox baseline.
• PBS now also receives the Outpost’s durable Climb datasets (Forgejo, Vikunja, curation records) under the §5A/§9 backup exception, via ZFS send; ephemeral forks excluded (§5A).
• §6B records that the Climb’s forge/tracker are reached as Beta web services via Traefik, not through the Air-Lock.
• §3B relabelled “GitLab Core (The Forge)” → “Kitchen production GitLab (secret-bearing)” to disambiguate it from the free community Forgejo now on the Outpost.
• §8 added the Outpost dual-purpose RAM/concurrency pressure (#6), the pending Climb deployment (#7), and the carried LDAP-Beta placement flag (#8); sharpened the auction-hardware note (#5).
• Climb additions throughout are marked (pending deployment) — selected, not yet stood up.

v1.0 (2026-06-02)

• Initial document, extracted from Constitution v9.3 §3 during the Charter Split refactor.
• All values carried forward from Constitution v9.3 §3A–3D without substantive change.
• Open questions §8 added to flag information gaps that should be filled during the next operational review.

END OF DOCUMENT

• Tier 0 — Keystone: Opplet Constitution
• Tier 1 — Doctrine & Architecture: Enclave Doctrine, Commons Doctrine, WiseNxt Doctrine, Workplace Doctrine
• Tier 2 — Operations & Learning: Enclave SOP, Enclave Bootcamp, Commons SOP, Commons Welcome, WiseNxt SOP, WiseNxt Orientation, Workplace SOP
• Tier 3 — Manifests & Reports: Software Stack, Hardware Manifest (this document), URL Nomenclature, Opplet.Com Website
• Tier 4 — Zone Projects: Den Migration