infra
infra provisions the homelab fleet with OpenTofu, used throughout in place of Terraform. Two operating models coexist behind a clean module-and-environment split: a libvirt-vm module brings up cloud-init Ubuntu VMs on KVM/libvirt, and a talos-cluster module stands up a Talos Linux Kubernetes cluster through the siderolabs/talos provider. The two are deliberately different. The Ubuntu VMs are bootstrapped here and configured downstream by Ansible, while Talos, an immutable API-only operating system with no SSH and no shell, is configured entirely by a declarative machine config and is never touched by configuration management.
Standing decisions live as architecture decision records (0001 through 0017): OpenTofu over Terraform, pre-1.0 providers pinned at the patch level, and a state-backend strategy where the lab uses a local backend while production state lives in an encrypted, lock-enabled S3-compatible remote backend. The environments (lab, production, talos-lab) are kept separate so a change is proven in the lab before it reaches production.
Every change runs through CI: tofu fmt and validate, TFLint, a Trivy infrastructure-misconfiguration scan, gitleaks secret scanning, native tofu tests against mock providers, and a CodeQL pass. Secrets are injected through environment variables, never committed to state or tfvars.
automation
automation is the configuration-management half of the fleet: an Ansible repository whose remit is everything Ansible does, hardening first. A compliance-aligned baseline of 19 roles (SSH hardening, AppArmor, kernel lockdown, USBGuard, an nftables egress firewall, auditd, AIDE, rkhunter, fail2ban, and rsyslog and systemd hardening among them) is applied by a single site playbook; three further roles, an SRE-toolchain installer, a local-inference runtime, and out-of-band Redfish/BMC management, run from their own playbooks. Twenty-two roles and four playbooks in total.
Technical controls are mapped to the regulations that govern them, in a machine-readable controls file: NIS2 (EU 2022/2555), the Austrian NISG 2026 transposition, the Cyber Resilience Act (EU 2024/2847), GDPR and the Austrian DSG, and ISO/IEC 27001:2022. Each role's defaults carry the cross-reference, and the control catalog is kept in sync with the role list.
It targets Ubuntu 24.04 LTS and the 26.04 LTS release, with the 26.04 baseline tracked as a kernel-7.0 delta over the CIS 24.04 benchmark while no official 26.04 benchmark exists. ansible-lint on the production profile (fully-qualified module names enforced), yamllint, and a Molecule test matrix gate every change; secrets live only in ansible-vault encrypted files.
isms
isms is an information-security management system managed as code, aligned with ISO/IEC 27001:2022, the Austrian NISG 2026, Implementing Regulation (EU) 2024/2690, and GDPR Art. 32. It is built in two layers: a reusable template framework full of placeholders, and one concrete per-organisation instance rendered from it, so the methodology is reusable without copying content between deployments.
Assurance rests on three independent evidence layers: signed Git history for authorship and integrity, eIDAS qualified electronic signatures (PAdES on the rendered PDFs) for formal approval, and continuous, append-only evidence collection. A suite of validators checks front-matter, cross-references, signature references, supersession chains, law citations, and bilingual parity; an auditor's clone plus one bootstrap command reproduces every artefact offline, with no runtime dependency on external services.
Authority-facing artefacts, such as the Austrian self-declaration and regulator correspondence, are authoritative in German; internal artefacts default to English. It is early-stage by design: the framework tooling is public while instance content stays confidential, and content population is ongoing.
relay-shell
relay-shell is a governed Model Context Protocol server for shell and SSH work, built so an operator can hand real administrative capability to an AI client without giving up control or visibility. One interface covers local shell execution, SSH command and session execution, SFTP transfer, port forwarding, and parallel fleet commands, including privileged flows (sudo, doas, and pkexec are treated as elevated-risk) when the deployment intentionally allows them.
Three policy modes set the posture, open, guarded, and read-only, and a global deny-list is evaluated first in every one of them. Every tool call passes through one central, audited runner: arguments are redacted of secrets, output is recorded as a SHA-256 hash rather than a raw body, and execution is bounded by timeouts, output caps, and idle-session reaping. The design keeps operational power intact and adds safeguards and auditability around it, rather than disabling features to feel safe.
The repository ships least-privilege CI alongside CodeQL, dependency review, pip-audit dependency-CVE scanning, and gitleaks secret scanning.
aiops-mcp
aiops-mcp (product name praxis) is a self-contained, security-first, single-operator, EU-sovereign AIOps control plane exposed over MCP. It fuses three things into one plane: a live bitemporal model of a heterogeneous host fleet (the source of truth), a drift engine that compares observed against desired state with human-gated convergence, and a tiered, audited actuator (the safe hands).
Nine load-bearing invariants hold the safety story together, each backed by a test: a single audited execution path no tool can bypass; a tiered authority model (T0 to T3) where classification rounds up and the highest tier needs a typed token and one target at a time; an append-only audit hash chain that stores an output hash and length, never the body; bitemporal, append-only state facts (invalidated, never deleted); host-type gating so a Talos node is never reached over SSH; a dry-run, then human-approval, then execute actuation flow; stdio by default with an SSRF egress filter on the opt-in HTTP transport; lethal-trifecta containment; and least privilege with a kill switch.
The execution core stays dependency-free (pydantic for input validation, psycopg for the optional Postgres backend); decisions are recorded as ADRs, every state-changing tool maps to a STPA unsafe control action, and v0 defaults to stdio with an opt-in HTTP transport, its limitations tracked openly in the repository.
nous
nous is a simulation-based digital twin of a man-portable edge-AI inference appliance, the kind a single operator might carry into a disconnected or contested environment. A tick loop drives per-subsystem physics (power, auxiliary power, thermal, compute, storage, sensors, position, biometrics, radios, inference, and propagation); recursive state estimators turn noisy observations into calibrated beliefs; a self-model layer aggregates those beliefs into honest capability claims with explicit uncertainty bands; and a mission-posture state machine governs what the device will do.
An LLM controller queries the whole surface over MCP, roughly fifty tier-classified tools behind an append-only JSONL audit hash chain that records output hashes rather than bodies. Because the device is meant for denied and intermittent links, its comms carry a store-and-forward outbox that triages held traffic by military precedence (routine through flash) and drains it as links recover, alongside a delay-tolerant mesh and emission-control postures. Interop adapters speak the formats a coalition expects: Cursor-on-Target / TAK, STANAG 4774/4778 confidentiality labels, MISB KLV, NMEA 0183, and OGC SensorThings; an OAuth 2.1 issuer lets it mount as a custom connector over HTTP.
It is simulation throughout, a model rather than a hardware-linked twin, with no fielded hardware. The point is to make an edge-AI appliance's behaviour legible to its controller: which capabilities are intact, which have degraded, and how long the device can sustain a given workload.
My other repositories are at github.com/rmednitzer.