Platform Services

Platform services cover the application-layer and operational tooling running on top of the core compute, storage, and networking layers. This section documents internal DNS, secrets management, the UniFi controller, Kafka and database design patterns, container build infrastructure, and certificate management.

Internal DNS

Four Technitium DNS Server VMs form a primary–secondary cluster serving the core.aorxi.io internal zone. sa-dns-01 (10.10.30.10) is the authoritative primary; sa-dns-02 (10.10.30.11) at Site A and sb-dns-01 / sb-dns-02 (10.20.30.10 / 10.20.30.11) at Site B receive zone transfers via AXFR — Site B secondaries pull over the WireGuard tunnel. OPNsense pushes DHCP lease registrations into Technitium via RFC 2136 dynamic DNS updates for VM Services (VLAN 30), Kubernetes Nodes (VLAN 40), and Lab / Trusted Client (VLAN 100). See DNS VMs for the full zone design, VM specifications, DDNS configuration, and cutover procedure.

Secrets Management — OpenBao

One OpenBao instance per site (sa-bao-01 at 10.10.30.40, sb-bao-01 at 10.20.30.40, VLAN 30) holds runtime secrets in a KV v2 homelab mount, consumed bao-first by Ansible and Pulumi with encrypted-file fallback as documented break-glass. No stretched Raft — cross-site DR is snapshot shipping, and unseal is cross-site transit over WireGuard (interim: Shamir manual unseal at Site A while Site B is down). See Secrets — OpenBao.

UniFi Controller — UOS

A single self-hosted UniFi OS Server (sa-uos-01, 10.10.10.40, VLAN 10) manages all standalone UniFi gear at both sites — Site B adopts over WireGuard via L3 adoption. The Cloud Gateways stay self-managed as bootstrap/fallback. See UniFi OS Server (UOS) Controller.

Kafka and Database Operations

Design notes cover Kafka blue/green deployment patterns and PostgreSQL performance tuning for workloads running on the homelab. The blue/green approach keeps separate Kafka clusters per environment, using MirrorMaker 2 for topic replication and a controlled producer/consumer cutover — green brokers do not join the blue cluster. Ordered consumer processing relies on partitioning by entity key so parallelism spans partitions while preserving per-key ordering within each partition. PostgreSQL observability guidance covers pg_stat_statements, slow query logs, lock waits, and the effect of audit logging (pg_audit) on transaction latency. See Kafka & Databases for the full patterns and tuning recommendations.

Container Build Infrastructure

Docker Compose tooling supports remote Supermicro hardware management during the build phase — primarily running the Supermicro Java iKVM client in a containerized GUI environment when physical access is unavailable. Key considerations include ARM/x86 architecture compatibility for 32-bit iKVM native libraries on Apple Silicon hosts and SMB 1.0 requirements for virtual ISO media mounting on older Supermicro IPMI firmware. See Container Infra for Dockerfile patterns, compose configuration, and known error conditions.

CA and Certificate Infrastructure

All HTTPS services use publicly-trusted Let's Encrypt certificates issued via Cloudflare DNS-01 — no HTTP-01 challenge server and no private CA root distribution required for browser-facing services. OPNsense uses the os-acme-client plugin; Proxmox and Proxmox Backup Server (PBS) nodes use acme.sh; Kubernetes clusters use cert-manager with a ClusterIssuer backed by the Cloudflare API token scoped to aorxi.io. A step-ca private CA runs on sa-ca-01 (10.10.30.30, VLAN 30) for IPMI/BMC certificates and internal mTLS where ACME is unsupported by the firmware. See CA & Certificates for issuer configuration, the full certificate inventory, and renewal procedures.