Overview

The Homelab Security Portfolio documents the design, implementation, operation, and continued maturation of a segmented enterprise-style homelab and cyber-range environment.

The project is intended to demonstrate security engineering rather than simply self-hosting applications. Its design emphasizes trust boundaries, least privilege, controlled change, independent recovery, security monitoring, validation, and explicit separation between implemented capabilities and future roadmap work.

The public portfolio is a sanitized derivative of the private operational environment. Operational identifiers, credentials, private network information, recovery artifacts, and other unnecessary infrastructure details are intentionally excluded or generalized.

Engineering problem

A useful security lab needs to support experimentation without collapsing every workload into a single trust domain.

The project therefore addresses several related engineering problems:

  • how to segment production, administration, CI, security monitoring, and cyber-range workloads;
  • how to provide externally reachable services without exposing router ports;
  • how to prevent CI infrastructure from becoming unrestricted production administration;
  • how to maintain recoverability outside the production failure domain;
  • how to collect security telemetry without creating unnecessarily broad firewall paths;
  • how to allow local AI to consume approved knowledge without making the AI system an infrastructure control plane;
  • how to document current, planned, and historical states without presenting roadmap work as deployed capability.

Architecture

The environment uses OPNsense as the authoritative inter-zone routing and firewall boundary.

Separate security zones support functions including:

  • trusted administration;
  • production applications;
  • CI/CD;
  • management and security monitoring;
  • ICS/OT;
  • Red Team activity;
  • OT DMZ services;
  • IoT and guest workloads;
  • future dedicated AI placement.

Proxmox provides virtualization, while Docker hosts the production application platform.

The public architecture deliberately uses sanitized addressing and functional system identifiers. The detailed public repository retains the architectural relationships and security controls while withholding unnecessary operational information.

Zero Trust ingress

Externally reachable applications do not require public router ports.

The normal application path uses:

Internet
    ↓
Cloudflare Access / Tunnel
    ↓
edge tunnel connector
    ↓
OPNsense
    ↓
Caddy
    ↓
application

Cloudflare provides the external identity and tunnel layer, while Caddy provides the internal reverse-proxy boundary.

Caddy is deliberately operated without routine access to the Docker socket.

This reduces the blast radius of the reverse-proxy tier and avoids treating container-engine control as a prerequisite for ingress.

Network security model

Inter-zone connectivity is based on narrow source, destination, and service requirements rather than broad east-west access.

The design favors:

  • explicit firewall rules;
  • default-deny policy;
  • dedicated trust zones;
  • controlled administrative paths;
  • limited telemetry exceptions;
  • clear separation between management and production workloads.

The firewall remains the routing authority between zones rather than allowing virtualization or application infrastructure to bypass the security boundary.

GitOps and isolated CI/CD

Infrastructure development follows a controlled Git workflow:

workstation
    ↓
feature branch
    ↓
pull request
    ↓
isolated CI validation
    ↓
approval
    ↓
main
    ↓
restricted production reconciliation

The CI environment is deliberately prevented from becoming production root.

It does not receive unrestricted production shell access or routine access to the production Docker socket.

Production deployment uses a constrained reconciliation path with validation and rollback rather than treating successful CI execution as automatic authorization to control production.

Recovery architecture

The recovery design evolved from same-host protection toward an independent backup failure domain.

The architecture incorporates:

  • a separate backup network identity;
  • narrowly scoped backup connectivity;
  • encrypted SMB transport;
  • fail-closed mount validation;
  • application-aware backup staging;
  • Restic-based retention;
  • restore validation;
  • separation between production storage and recovery storage.

The important design objective is not simply that backups exist, but that a production-host failure cannot silently redirect backup operations into the same failure domain.

Security monitoring

Wazuh provides the current security-monitoring foundation.

Telemetry includes endpoint and network-security sources, with firewall policy allowing only the required collection paths.

The implementation demonstrates both deployment and troubleshooting of a segmented SIEM architecture, including endpoint telemetry and firewall-log integration.

Wazuh recovery, retention, tuning, notification workflows, and additional hardening remain maturity work rather than being presented as completed capability.

Administrative trust

Administrative access is treated as a separate security problem rather than an extension of application access.

The environment uses independent administrative identities and SSH trust relationships across Windows and Linux systems.

Administrative workstations remain independently manageable rather than sharing a single universal credential or relying on CI infrastructure as a bastion.

This supports narrower revocation boundaries and limits the effect of a single compromised administrative identity.

Local AI security boundary

The local AI environment is intentionally constrained.

Model and dashboard services remain locally bound rather than operating as generally accessible network services.

Knowledge access is provided through a read-only MCP boundary restricted to approved derived knowledge roots.

The AI environment is therefore able to assist with documentation and knowledge retrieval without receiving unrestricted shell access, arbitrary filesystem access, infrastructure credentials, or production-control authority.

The AI system is explicitly not treated as an authoritative infrastructure control plane.

Validation model

Changes are evaluated using both positive and negative tests.

Validation includes concepts such as:

  • confirming intended communication paths;
  • confirming prohibited paths remain blocked;
  • service-health checks;
  • backup verification before risky changes;
  • recovery and rollback capability;
  • configuration comparison;
  • security telemetry validation;
  • documentation review.

Runtime evidence takes precedence over stale documentation when the two disagree.

Engineering decisions

Several architectural decisions are intentionally conservative.

CI remains isolated from production control.

Backups remain outside the production failure domain.

Application ingress does not require public router ports.

The reverse proxy does not require the Docker socket.

The firewall remains the authoritative inter-zone boundary.

Local AI remains constrained and read-only with respect to approved knowledge.

These decisions trade some convenience for reduced blast radius, clearer trust boundaries, and more predictable recovery.

Current maturity

The following foundations are currently operational and represented in the public portfolio:

  • segmented OPNsense network architecture;
  • production Docker application platform;
  • Cloudflare-protected ingress;
  • Forgejo-based Git workflow and isolated CI;
  • independent Restic-backed recovery;
  • Wazuh security-monitoring foundation;
  • multi-workstation administration;
  • constrained local AI;
  • read-only AI knowledge access.

Several areas remain active maturity work:

  • selected SSH hardening;
  • firewall reconciliation and additional policy hardening;
  • Wazuh recovery, retention, tuning, and notifications;
  • Docker reproducibility and selected runtime drift;
  • observability modernization.

The following remain roadmap items and are not represented as completed implementations:

  • final Grafana and Prometheus observability architecture;
  • full ICS/OT cyber-range workload implementation;
  • Red Team exercise integration;
  • migration of local AI into the dedicated AI VLAN;
  • final semantic RAG and vector-retrieval architecture.

Lessons

The project reinforces several broader engineering principles.

Security boundaries are more valuable when they are explicit and testable.

CI should validate changes without automatically inheriting production authority.

Recovery architecture is part of security architecture.

Observability and SIEM systems require the same trust-boundary discipline as production applications.

Documentation should distinguish what exists from what is intended.

AI integration should begin from minimum authority rather than adding controls after broad access has already been granted.

Detailed engineering evidence

The public GitHub repository contains the detailed sanitized engineering material, including:

  • architecture documentation;
  • network-segmentation design;
  • trust-boundary analysis;
  • security design principles;
  • GitOps and CI/CD architecture;
  • Zero Trust ingress;
  • backup and recovery architecture;
  • SSH trust modeling;
  • Wazuh SIEM documentation;
  • local AI security boundaries;
  • architecture decision records;
  • validated case studies.

View the Homelab Security Portfolio