Software Stack

Opplet Operations: Software Stack Manifest

Version 1.6 · 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 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 versions are deployed right now.

Version cells marked TBD are known gaps to be captured during the next operational review (see §8). Cells marked pending deployment name a service that is selected but not yet stood up — currently the WiseNxt Climb stack (§5B), selected per WiseNxt SOP v1.4.

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

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

The Hardware Manifest specifies these Engine workloads by function and RAM only; the specific products and versions are recorded here once captured.

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.

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

Service versions are tracked here and reviewed on the cadence defined in the SOP. Upgrades follow the SOP’s change procedures; this Manifest is updated to match the deployed state after each upgrade lands. The Hardware Manifest (§7) points here as the canonical record of Proxmox, Incus, and Debian releases. Pending-deployment entries (§5B) convert to tracked versions once the Climb stack is stood up.

8. Open Questions for Future Refresh

1. All version numbers. Every cell marked TBD above needs its deployed version captured during the next operational review.
2. Den Engine products. The specific software behind each personal-service function (Identity/SSO, file sync, automation, CRM, finance, tasks, CalDAV/CardDAV, dashboard, credential storage) needs to be recorded.
3. Gateway control panel. Product not yet captured.
4. CI/CD runners — resolved. The Kitchen Build Farm runs GitLab Runner (matching the Kitchen GitLab); the Climb’s CI runs Forgejo Actions (§5B). Versions still TBD.
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; capture 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.
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

• 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 (this document), Hardware Manifest, URL Nomenclature, Opplet.Com Website
• Tier 4 — Zone Projects: Den Migration