A single source of truth. Every host, subnet, and service is declared once and generates everything downstream from it: Terraform resources, GitOps manifests, DNS records, reverse-proxy config. Nothing hand-duplicated.

Keeping a physical switch's config honest:

• The CBS350 switch's intended config is a real Jinja template in this repo, not a backup nobody looks at again
• Nautobot's Golden Config app renders it, commits the output back into this same git history, and diffs it against the switch's actual running config
• RADIUS/AAA and LibreNMS SNMP/LLDP monitoring run against that same physical switch — not just VMs

Authenticating a user, one real identity for every app:

• Every app traces back to the same Microsoft Entra ID account — no separate password per service
• Authentik fronts everything as the single SSO broker: OIDC where supported, SAML for the one app that only speaks that, forward-auth for the rest
• Each app's own <service>-read/-edit/-admin Authentik groups gate access, generated automatically, not hand-provisioned
• A local emergency-fallback account exists on a handful of services as a break-glass path, not day-to-day login

Reaching an app remotely, with no open inbound ports:

• Nothing on the home network ever accepts an inbound connection
• A Ziti client dials out to the public controller, which brokers an outbound-only tunnel back to Traefik
• Traefik is the same reverse proxy every request goes through, local or remote, enforcing the Authentik SSO gate before most apps are reached

Shipping a change, GitOps-style:

• Every change to this repo, including the numbers on this page, flows through the same pipeline: commit, reconcile, apply
• No manual kubectl apply, no clicking through a UI

Enrolling a new user, without ever hand-provisioning an account:

• The intake form is the only thing a not-yet-provisioned person can reach — no Ziti identity yet, so it runs over a narrowly-scoped public tunnel, not the zero-trust overlay above
• Approval is a single human decision that produces a git commit, not a rubber stamp on a database write
• Terraform is still the only thing that ever creates the account — same GitOps pipeline as everything else, just triggered by a Slack click
• A symmetric offboarding flow tears the account back down the same way

Rebuilding from an empty Proxmox cluster:

• Everything in this repo except a short, explicit list of local secrets lives in git — clone it, reconnect Bitwarden Secrets Manager, and most of the state is back
• Every VM, the Kubernetes cluster, and the app layer on top come back from a documented sequence of Terraform applies, in a fixed dependency order
• Installing the hypervisor OS, creating VLANs on the firewall, and pushing config to the physical network hardware are genuine manual steps — the runbook calls them out explicitly rather than glossing over them
• Everything downstream of that, including this page's own live stats, rebuilds itself with zero further manual steps

terraform/
├── blueprints/            42 reusable modules, grouped by category
│   ├── compute/
│   ├── containers/
│   ├── kubernetes/
│   └── ...
├── environments/
│   ├── 01-globals/        the single source of truth
│   │   ├── hosts.hcl      every VM and physical host, declared once
│   │   ├── network.hcl    every VLAN and subnet
│   │   ├── services.hcl   every app: routing, auth, hosting tier
│   │   └── variables.hcl  shared type contracts every module validates against
│   ├── core/ · dev/ · prod/  one small terragrunt.hcl per deployed unit
│   └── root.hcl           centralized inputs, wired into every unit above
└── modules/                shared logic reused across many blueprints

Last synced: 2026-11-01T07:44:37Z