From physical hardware
to useful services.

1. Physical hosts provide the capacity.

Three physical systems form a Proxmox VE cluster: two compact AMD machines and an HP rack server. A separate Lenovo Linux host runs selected operational services. The QNAP NAS provides shared storage for selected application data and backup-related uses.

The hardware has different capacities. This matters for VM placement and failover: a workload that fits on the largest server does not necessarily fit on either compact machine. See the hardware and its trade-offs →

2. Virtual machines provide operating-system boundaries.

Proxmox guests separate environments such as general application hosting, databases, DNS, the reverse proxy and logging. Some applications share a Linux environment, while other responsibilities use a dedicated guest. The public diagram describes those roles without reproducing the private VM inventory or placement.

Selected guests use HA and ZFS replication. These features do not imply that all applications have active replicas or that every host is an eligible recovery destination.

3. Docker Compose describes most application stacks.

A stack can be one container or several cooperating components. Paperless, for example, combines an application with a Redis broker, an external PostgreSQL dependency and document storage. The container image is only one part of that service.

Each stack has configuration, runtime dependencies and a data footprint. Those are documented together in the service catalogue.

4. Shared services connect the applications.

BIND9 supplies internal authoritative names. AdGuard has a separate DNS-filtering role. Traefik maps named HTTPS requests to web backends. MySQL, PostgreSQL and Redis provide data services where applications need them. The NAS supplies selected persistent mounts.

These are shared dependencies, not invisible plumbing. Losing a database can affect several applications even if their containers are still running. Follow a request through DNS and the proxy →

5. Operations run alongside the applications.

Git holds intended configuration; Ansible and Semaphore apply server configuration and individual tasks; existing GitHub workflows deliver application stacks. Zabbix collects monitoring signals, Elastic helps investigate events, and Kuma provides a secondary reachability view.

Proxmox Backup Server adds VM-level backups, but recovering a service still requires its complete set of data and dependencies. This is why deployment, monitoring and recovery are separate documentation sections.

A concrete example: Paperless.

The processing path also includes background work and a dedicated Redis broker. A correct frontend response does not validate every stage. The Paperless guide explains the service as a whole.

Where this architecture stops.

This is an explanation of responsibilities. It deliberately omits addresses, internal names, access paths, firewall rules, physical network wiring and sensitive workloads. It also avoids treating documented deployment as a live availability claim.