The operating footprint
The environment is built to remain understandable as its dependencies multiply.
The three-node Proxmox cluster provides the compute core, but the operating environment extends beyond compute. Applications, management services, DNS, backups, publishing, remote access, storage, and recovery each have dependencies that cross physical and logical boundaries.
Those dependencies are deliberately separated rather than collapsed for convenience. Network functions do not share every failure domain with servers; DNS has an independent secondary; remote access has multiple paths; storage and backup remain distinct concerns. The objective is not maximum redundancy. It is preventing one ordinary failure from becoming an unnecessarily broad one.
Resilience
Availability depends on preserving capabilities, not simply keeping individual machines running.
Cluster quorum, replicated workloads, independent DNS, backup targets, network separation, and power management address different failure modes. None is treated as proof that a service is resilient merely because its process remains healthy.
Power follows the same principle. Network equipment and compute have separate power paths, allowing basic connectivity to survive when servers are unavailable. UPS capacity provides time for controlled shutdown, while NUT coordinates server behavior. Resilience therefore includes graceful degradation: preserving enough capability to understand the failure, communicate with the environment, and recover deliberately.
Operability
The environment is organized so failure does not require rediscovering how it works.
Configuration, physical layout, addressing conventions, cabling, dependency maps, and runbooks reinforce one another. The repository documents the cluster, network, DNS, remote access, certificates, publishing, backups, application tiers, recovery procedures, and incident history.
Recovery follows dependency order rather than application visibility. Power precedes WAN; networking precedes DNS; infrastructure precedes compute; compute and storage precede applications. The sequence matters because the most visible failure is often downstream of the actual one. Troubleshooting begins with prerequisites rather than symptoms.
What it means
The environment is not designed around the assumption that every component remains available. It is designed so failures stay bounded, surviving capabilities remain useful, and recovery follows a known dependency order. Complexity is acceptable when it improves containment, resilience, or operability—not merely because the hardware permits it.
Evidence and limits
The documented footprint reflects the current operating record and confirmed configuration. Runbooks, incident history, and observed behavior provide evidence of how the environment operates; they do not imply that every recovery path has been rehearsed or that documented intent and current state can never diverge.