Software Stack

Opplet Operations: Software Stack Manifest

Version 1.6 · DRAFT (reconciles to Constitution v12.8) · Tier 2 — Tier 2 — Manifests & Reports · part of Charter Release 2026.3 · effective 2026-06-25

Purpose and Scope

This document records the software running on every node in the enclave — operating systems, the hypervisor layer, the container runtime, and the deployed version of each service. It is the software companion to the Hardware Manifest: where that document records the physical machines and their RAM allocations, this one records what runs on them.

Like the Hardware Manifest, it is operational truth, not architectural law. Software upgrades update this document; they do not bump the Constitution. The Constitution and the per-service architecture define which services exist and why; this Manifest records which version of each is the standing target — pinned to the deployed release as the enclave is built out and audited (§7, §8).

Version cells carry a standing target, not a captured release: latest stable means the service tracks upstream’s latest stable, deployed under the cadence rule (§7); pending deployment names a service that is selected but not yet stood up — currently the WiseNxt Climb stack (§5B), selected per WiseNxt SOP v1.4; n/a marks a layer to which no version applies; and TBD is reserved for the rare cell where the product itself is not yet chosen. As the enclave is built and audited, latest-stable cells are pinned to the actually-deployed release (§7, §8).

1. Platform Baseline

The common substrate shared across nodes.

The Manor and Annex run Proxmox VE on Debian (Constitution §5E, Hardware Manifest §7), using Proxmox LXC for system containers and KVM where full-VM isolation is required. The Outpost runs Incus on Debian — chosen deliberately for the range’s ephemeral-fork workload (lease → clone from template → run → recycle), where Incus’s ephemeral instances, project isolation, and copy-on-write clones fit better than a general hypervisor. The Den VPSs run Ubuntu Server directly — native services on the Gateway, Docker on the Engine, no nested hypervisor.

2. The Den — Zone 1 (Sovereign Life)

2A. Gateway VPS (“The Front Door”) — native services, no Docker

HestiaCP is the Gateway’s management plane: it provisions and manages the mail stack (Exim + Dovecot + SpamAssassin) and the Nginx reverse proxy listed above, rather than those being maintained independently. Telephony (FreePBX / Asterisk) is managed separately.

2B. Engine VPS (“The Workshop”) — Docker containers

The Hardware Manifest specifies these Engine workloads by function and RAM only; the products are named here. Four are Den instances of products already in the enclave — Authentik-Den (cf. Authentik-Business, §3A), n8n-Den (cf. n8n-Alpha, §3A), Vaultwarden-Den (cf. Vaultwarden-Biz, §3A), and Vikunja-Den (cf. the Climb’s Vikunja, §5B). They run on the Den’s own VPSs, on the Sovereign-Life side of the two-world boundary (Constitution §3): they share a product, not a deployment.

Recorded calling. Calls placed through the system (softphone, SIP, or desk phone) are recorded by Asterisk (MixMonitor) on the Gateway; n8n writes the call and a link to its recording into Monica as a Conversation / Call entry. Calls on a carrier’s native dialer never traverse the PBX and are out of scope.

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

3A. Zone 0 — Basement

Both directories are hosted in the Basement (Zone 0), served by Authentik-Business, even though LDAP-Beta governs the commons hosted outward across the Lounge and the Range. The directories live where they are most protected; authentication reaches outward from there (Enclave Doctrine §2, §3).

3B. Zone 2 — Office

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

4A. Zone 3 — Kitchen

The Kitchen production GitLab is the secret-bearing production forge (Constitution §4); it is distinct from the free community forge (Forgejo), which is the Climb’s and lives on the Outpost (§5B). Vetted code is promoted free → Kitchen by one-way mirror; secrets never flow outward.

4B. Zone 4 — Lounge

HumHub also hosts the potential-climbers space that broadcasts entry vacancies for the Climb (WiseNxt SOP §6). Moodle delivers all Commons courses — Welcome to Opplet Commons (candidate → member), Enclave Bootcamp (member → certified member), the WiseNxt Orientation (the Climb on-ramp), and the Opplet-thematic courses. The Range hosts no courses (Constitution §11.3); the WiseNxt Orientation’s hands-on work-discovery runs on a Range fork via the Air-Lock (§5B), but its course delivery is here in Moodle.

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

Runs Incus (§1).

5A. Live-fire range

Range target software is intentionally variable — it is provisioned per exercise and is not held to the version-stability expectations of the rest of the enclave (§7).

5B. The Climb — the WiseNxt stack (LDAP-Beta)

Selected per WiseNxt SOP v1.4 §9; on the Outpost per Constitution §1–§2. Pending deployment.

No courses run on the Range. All LMS courses are Moodle-hosted in the Lounge (§4B; Constitution §11.3). The forge’s public-read projects are the source of truth and the newly-developed work exemplars that certified members (Opplet Learner Permit holders) review as an ordinary Beta web service (Constitution §11.3, §5C) — read access via Traefik, distinct from the Air-Lock fork path used to operate.

Durability. The forge and the tracker are the durable services; their datasets are backed up to Proxmox Backup Server under the Outpost backup exception (Constitution §5A, §9) — on the Incus host this is via ZFS send / file-level backup rather than native PVE integration. The practice forks are ephemeral, rebuilt from templates, and are not backed up. The Climb’s services federate to Authentik-Business (Beta) for SSO (§4B) and are wired by n8n for fork provisioning, grade write-back, seat provisioning, and the entry-vacancy broadcast to the HumHub potential-climbers space (§4B).

6. Cross-Cutting Software

7. Version Policy

Services track upstream stable. The standing target for every service whose product is chosen is latest stable; the Tech Board sets the window within which a newly-released stable version must be deployed after its release — currently [window TBD — Tech Board] — and upgrades follow the SOP’s change procedures. The live-fire range targets (§5A) are exempt: their software is provisioned per exercise and is not held to the enclave’s version-stability expectations.

This Manifest is the canonical record of the Proxmox, Incus, and Debian releases (Hardware Manifest §7 points here). As the enclave is built and each service is stood up, its latest stable cell is pinned to the actually-deployed release during the operational review (§8); pending-deployment entries (§5B) convert to tracked versions once the Climb stack is stood up.

8. Open Questions for Future Refresh

1. Version pinning. The standing target is latest stable (§7); the actually-deployed release for each service is pinned during the operational review as the enclave is built out. The Tech Board’s deployment window (§7) is still to be set.
2. Den Engine products — RESOLVED (v1.7). The Engine stack is named (§2B): Authentik-Den (SSO), Seafile (file sync), n8n-Den (automation), Monica (CRM), Firefly III (finance), Vikunja-Den (tasks), Radicale (CalDAV/CardDAV), Homepage (dashboard), Vaultwarden-Den (credentials). Four are Den instances of existing enclave products; the rest are new to the stack.
3. Gateway control panel — RESOLVED (v1.7). HestiaCP (§2A), managing the Gateway mail stack and Nginx.
4. CI/CD runners — resolved. The Kitchen Build Farm runs GitLab Runner (matching the Kitchen GitLab); the Climb’s CI runs Forgejo Actions (§5B).
5. Enclave container model — partially resolved. The Manor and Annex use Proxmox LXC (and KVM); the Outpost runs Incus, with the range forks as Incus system containers (§5B). The full per-service VM-vs-container convention on the Proxmox nodes is still to be confirmed.
6. Climb stack versions. The §5B services (Forgejo, Forgejo Actions, Vikunja, the grader) are selected but not yet deployed; pin versions once stood up.
7. Beta automation instance. Confirm whether the Climb’s Beta-side n8n is a distinct n8n-Beta instance or n8n-Alpha reaching Beta under the Janitor Rule (Constitution §5A), and record it. (Independent of n8n-Den, §2B, which is the Sovereign-Life instance.)
8. Alpha workplace LMS. The real-identity workplace has no LMS by default — onboarding is documentation plus a human/contract process (a Workplace matter). If trackable, certifiable training is later required, the designated option is Frappe LMS on the existing ERPNext/Frappe stack (Alpha-side, Office / Zone 2), not a separate Moodle, keeping it on the Alpha side of the two-world boundary (Constitution §3). A Workplace SOP decision if and when the need arises.
9. LDAP-Beta location — RESOLVED (v1.6). LDAP-Beta is hosted in the Basement (Zone 0) alongside LDAP-Alpha, both served by Authentik-Business (§3A) — matching Enclave Doctrine §2. The directory lives in the most-protected zone and authenticates outward to the Lounge and Range. The prior Kitchen (Zone 3) listing, inherited from the v1.0 manifests, conflated the directory’s host with the population it serves and is corrected.

END OF DOCUMENT

Pages describing Opplet’s approved state based on this document:

• GitLab — written against v1.6, current

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