Infrastructure Asset Register

How to Read This Register

In one sentence: this page is the single source of truth for what hardware and logical infrastructure exists behind this portfolio, what state each asset is in, and what evidence backs each claim.

Every asset carries one of four verification statuses. They mean specific things and are never blurred:

• CONFIRMED: direct evidence exists on this site or in the lab itself: a photograph, a configuration that is applied and running, or output captured from the live system. The server room page is the photographic record for the confirmed rows.
• PARTIALLY VERIFIED: the asset has been stated by the owner (the person who runs this site) but independent corroborating evidence has not yet been published: no photo, no captured inventory output, no serial-level record. Treat the quantity and model as accurate to the owner's account, pending the evidence items in the verification checklist below.
• PLANNED: an intended future capability. Designed and scoped, not purchased or deployed. Nothing in a PLANNED row should be read as operational.
• UNKNOWN: insufficient evidence to record a value at all. The field is left marked rather than filled with a guess.

Two rules follow from the site's documentation philosophy (evidence first, explanation second, presentation third). First, this register never converts an owner statement into a confirmed fact; status changes only when evidence lands. Second, physical assets, virtual machines, containers, and logical services are kept in separate inventories: a Kubernetes node is a VM on a Proxmox host, not a physical server, and counting it as one would double-count the fleet.

Register last reconciled: 2026-10-21. Evidence source for all non-CONFIRMED rows: owner statement, 2026-10-21 (updated the same day with configuration-level testimony for the GPU stack nodes and the estate's build sequence), unless a row says otherwise.

Physical Asset Register

Confirmed rows describe the running lab documented on the Homelab Server Room page. Expansion rows describe the stated next phase of the build. Specifications are recorded only where known; empty fields are marked UNKNOWN rather than estimated.

Confirmed, in daily use

Exact makes and models of the confirmed desktops and laptops, their CPU and RAM configurations, and per-node power draw have not been published yet; capturing lshw and dmidecode output per host is item 1 in the verification checklist below. No wattage figures are claimed anywhere on this site because none have been measured.

Owner-stated expansion inventory (pending independent evidence)

The rows below were stated by the owner on 2026-10-21 as the next phase of the build. Until photographs, inventory captures, or configuration exports are published, they carry PARTIALLY VERIFIED or PLANNED status and must not be read as deployed infrastructure.

Power protection, cooling capacity, and backup hardware for the expansion phase are recorded as UNKNOWN until measured. The 9 kW electrical implication of the GPU cluster is worked through in the feasibility section rather than assumed away.

Logical Infrastructure Inventory

Logical assets ride on the physical rows above. VM counts are documented on the Kubernetes Infrastructure page; they are not physical machines and are not double-counted here.

Master Architecture Diagram

One picture of the whole estate: confirmed layers are drawn with solid lines and filled nodes, and owner-stated assets (the three hosting stacks, the 24-unit OptiPlex fleet, the JBOD storage, the Cisco switching, the Raspberry Pi utility server, the media library, and the separate 20-node GPU rental stack) with dashed lines until independent evidence is published. The diagram distinguishes the physical layer (racks, hosts, network) from the virtualization layer (Proxmox), the orchestration layer (Kubernetes), and the service plane (DNS, AI, monitoring, backups, public domains).

Reading guide: solid arrows are paths that carry traffic today. Dashed arrows are owner-stated relationships awaiting independent evidence. The GPU rental stack links into the estate through the switching layer, but its power and mechanical integration is exactly the open question the feasibility analysis below addresses.

Storage Capacity Model: Raw, Usable, Planned

The stated figure for the expansion phase is approximately 2 PB of intended aggregate capacity across 4 JBOD enclosures. Until the enclosure models, bay counts, and drive populations are evidenced, that number is an intended raw target, nothing more. Three distinctions matter before the number is quoted anywhere:

• Raw capacity is the sum of the label capacities of every physical drive. It is the largest number and the least useful one for planning.
• Usable capacity is what remains after redundancy (parity or mirroring), filesystem and metadata overhead, and sensible free-space headroom. Parity schemes commonly cost one to four drives per vdev; filesystem overhead and reservation typically cost a further few percent.
• Backup copies consume capacity again. A 3-2-1 posture (three copies, two media, one off-site) means protected data needs roughly double the usable capacity of the primary copy somewhere in the estate.

Illustrative arithmetic only (not a measurement, and not this lab's configuration): 2.0 PB raw, minus 20 percent for dual-parity redundancy, minus roughly 3 percent filesystem overhead, yields on the order of 1.5 PB usable for the primary copy, before any backup copy is carved out. The real number will be computed from the actual drive population once the JBOD rows above move from PARTIALLY VERIFIED to CONFIRMED, and this section will be updated with the measured split.

One further rule this site applies everywhere: replication is not backup. A replicated or mirrored copy faithfully reproduces accidental deletion and corruption. Independent, point-in-time recovery points (snapshots plus off-host copies, as documented on the Data Sovereignty Stack page) are what make recovery possible.

GPU Cluster Feasibility: OptiPlex 5060 SFF vs RTX 4090

The owner states the stack is twenty OptiPlex 5060 SFF units (8th-gen Core i7-8700, 16 GB DDR4-2666, 2x DisplayPort, Gigabit Ethernet) each paired with an RTX 4090-class GPU, racked separately and reserved for rental workloads. Before that statement can be taken at face value, the chassis and power numbers have to be confronted, because a 450 W RTX 4090 cannot simply be assumed to fit and operate safely inside an unmodified Small Form Factor office PC. The comparison below uses the manufacturers' own published specifications (sources linked in the references).

Conclusion: the OptiPlex 5060 SFF cannot host an RTX 4090 unmodified. The owner reports the GPU stack is already built, which means one of three things must be true for every node, and the register records it honestly as an open documentation gap:

• the stock 200 W PSU was replaced or supplemented (for example an external ATX or server PSU feeding the card's 16-pin connector), or
• the card sits outside the closed SFF chassis on a PCIe riser or open-frame mount, or
• the installed cards are not actually RTX 4090 reference-class parts.

Two evidence items resolve this completely: a photograph of one open node showing the card mounting and power cabling, and the nvidia-smi --query-gpu=name,power.limit --format=csv output from one node. A further naming note: the owner specification says "4090 Ti", but NVIDIA has not released an RTX 4090 Ti SKU as of this writing, so the cards are recorded as RTX 4090-class until the model string is captured. If the stack is ever rebuilt or expanded, the realistic platform options, in order of increasing effort:

• Tower workstations: full-size towers with 750 to 1000 W+ PSUs and full-length x16 slots (for example Dell Precision or Lenovo ThinkStation class towers) host one 4090-class card each with stock cooling. Highest per-node cost, lowest engineering risk.
• Open-frame GPU nodes: rack-mounted open frames with server-grade 1600 W+ PSUs and PCIe risers, the standard pattern for multi-GPU density. Cheap per slot, but demands deliberate cable, vibration, and dust management.
• SFF-respecting alternative: keep the OptiPlex 5060 SFF fleet for what it is genuinely good at (Proxmox nodes, network services, control-plane duties) and, if GPU-in-SFF is ever required, use low-profile 70 W cards in the RTX A2000 / RTX 4000 SFF Ada class that are engineered for exactly this chassis constraint, accepting their much smaller VRAM and throughput.

Electrical planning is part of the same question. Twenty 4090-class cards imply roughly 9 kW of GPU load alone, and 12 kW or more once CPUs, memory, storage, and cooling overhead are included. A single North American 15 A / 120 V household circuit supplies about 1.8 kW maximum, so a stack of this size needs multiple dedicated circuits, and realistically 240 V feeds, plus heat rejection for a continuous multi-kilowatt load in a residential basement. These are solvable problems, but they are electrical and HVAC projects in their own right, and they are recorded here as open engineering questions rather than glossed over.

Status of the GPU stack: PARTIALLY VERIFIED, owner-stated as built and reserved for rental workloads, with the power/mechanical integration and the exact GPU model string undocumented. No performance, uptime, or revenue claims are made anywhere on this site for it.

Build Process: How the Estate Was Assembled

This narrative reconstructs the build from the owner's account (2026-10-21) combined with the photographed and documented evidence for the confirmed layers. Steps that rest on owner testimony alone say so; nothing here is presented as independently verified unless it is. The confirmed basement lab build is documented separately on the Homelab Server Room page; this section covers the larger estate.

Legal, Licensing, and Operational Considerations

• Media library: self-hosting media is lawful for content the owner holds rights to; this website does not host, index, link to, or redistribute any media, and the library is a private system on the owner's own network. Nothing on this page should be read as offering media access to anyone else.
• GPU rental workloads: renting compute to third parties creates obligations the estate must meet before any tenant runs anything: an acceptable-use policy, tenant isolation at the network and hypervisor layers, abuse handling, and logging sufficient to attribute tenant actions. None of these are documented yet; they are prerequisites, not afterthoughts, and no rental service is claimed to operate.
• Pi-hole and monitoring privacy: DNS query logs and network telemetry about household devices are personal data in practice. They stay on the utility server, are not published, and retention is kept minimal.
• Domain watchdog scope: the automation detects failures and drives a recovery runbook. It is resilience against DNS, certificate, and hosting failures, not a mechanism to circumvent registrar, registry, or legal actions.
• Electrical and fire safety: a multi-kilowatt continuous load in a residence needs circuits, PDUs, and heat rejection designed for it. This is an electrician-and-insurance conversation before it is a server conversation.

Verification Checklist: Evidence to Collect

These are the concrete evidence items that will move rows from PARTIALLY VERIFIED or UNKNOWN to CONFIRMED. Commands are labeled by the environment they run in. Placeholders in angle brackets are environment-specific values the operator supplies; nothing here publishes serial numbers, MAC addresses, or private IPs, which are recorded privately and summarized publicly.

sudo dmidecode -t system | grep -E "Manufacturer|Product Name"
sudo lshw -short -C cpu -C memory -C disk
lsblk -d -o NAME,MODEL,SIZE,ROTA

sudo smartctl -a /dev/<disk> | grep -E "Model|Capacity|Power_On_Hours|Reallocated"

pvesh get /nodes --output-format json
qm list
kubectl get nodes -o wide

References

Sources for the specifications quoted above. A vendor specification sheet establishes what a product is; it does not establish that this lab owns one, which is why these citations support the feasibility analysis and not the asset statuses.

• Dell, OptiPlex 5060 Small Form Factor Setup and Specifications: Power supply, 200 W EPA Bronze/Platinum PSU. Supports the PSU row of the feasibility table.
• Dell, OptiPlex 5060 SFF Setup and Specifications, chassis dimensions 292 x 290 x 92.6 mm, half-height PCIe 3.0 x16 + x4 slots, 4 DDR4 UDIMM slots (64 GB max). Supports the slot, clearance, and memory rows.
• NVIDIA, GeForce RTX 40 Series Power Specifications, RTX 4090 TGP 450 W, minimum recommended PSU 850 W, 16-pin connector guidance. Supports the power rows of the feasibility table.
• CNET, Nvidia GeForce RTX 4090 review, specification table, Founders Edition dimensions 304 x 137 mm, 3-slot, 24 GB GDDR6X. Supports the physical size row.
• IT Pro, Dell OptiPlex 5060 review, independent confirmation of the SFF chassis dimensions (93 mm wide). Corroborates the Dell dimensional specification.