A small pile of computers, with a plan.

The shape of the system

The cluster provides a common place to manage Linux containers and virtual machines. A primary application guest runs many Docker services; other guests separate household automation, monitoring, file services, and specialized workloads. A fourth host adds dedicated GPU compute.

The daily-driver workstation is separate from that cluster and also supplies local language-model inference.

flowchart TD
  accTitle: Public and private application access
  accDescr: Public visitors reach selected web applications through the public Caddy edge. Household clients use the private service path for household services. These are simplified access paths, not a complete network inventory.
  Public["Public visitors"] --> Edge["Public edge / TLS"]
  Household["Private clients"] --> Private["Private access"]
  Edge --> Apps["Web applications"]
  Private --> Services["Household services"]

Reading the map: arrows show simplified request paths. Public applications can still require an account. This is a web/application overview, not an exhaustive network inventory or a claim that every service follows the same ingress path.

Why split the workloads?

flowchart TD
  accTitle: Compute responsibilities
  accDescr: Four Proxmox nodes manage purpose-specific guests for applications, automation and GPU services. Cluster management is not automatic replication or failover.
  Hosts["Four Proxmox nodes"] --> Guests["Purpose-specific guests"]
  Guests --> Apps["Apps + automation"]
  Guests --> GPU["GPU services"]

Purpose-specific guests make placement, resource use, and recovery easier to understand. Home Assistant has device passthrough requirements. Monitoring should remain useful when an application guest has trouble. GPU services need a different host profile than lightweight web applications.

Docker Compose keeps application services and their configuration together. It does not replace the host-level responsibilities of storage, networking, backup, or capacity planning.

The hardware

As of October 2026, the cluster is four small machines, all bought used or reused:

• Primary application host: an HP ProDesk 400 G4 Mini (Intel Core i5-8500T, 6 cores, 16 GB). It runs the main application guest. Bulk storage lives on two external drives attached over USB 3. It replaced a fanless mini PC that failed in October 2026; that day has its own story. It also needs a small HDMI dummy plug to stay up without a monitor.
• Two utility nodes: Lenovo ThinkCentre M710q Tiny machines (Intel Core i5-7500T, 4 cores, 8 GB each). They host Home Assistant, monitoring and smaller services.
• GPU node: a small desktop with an Intel Core i5-10400F, 16 GB and an NVIDIA GTX 1660 SUPER for speech, text-to-speech and other GPU services.

The daily-driver workstation, outside the cluster, is the largest machine in the house.

Supporting layers

• Networking & access: DNS, TLS, public routes, and private access are related but distinct responsibilities.
• Monitoring: service health, host metrics, event feeds, and stale-data handling.
• Backups & recovery: application-consistent data, local recovery copies, encrypted off-site copies, and tested procedures.
• Local AI: workload-aware inference on the workstation and dedicated GPU services in the lab.

Constraints worth stating

This is a household environment built with a mixture of low-power and reused hardware. The cluster does not currently provide shared VM storage and automatic application failover. Bulk storage is not a redundant pool, so protection depends on explicit backup coverage and recovery planning.

A four-node cluster also needs three votes for quorum under its current arrangement. Losing one node can preserve quorum; that does not guarantee the workloads on that node remain available. October 2026 is the worked example: the cluster kept quorum, and everything on the failed node still went dark until it was restored.

Those limits inform the design. The goal is to understand the failure domains and recover deliberately, rather than attach an enterprise label to a small system.