Homelab Decision Kit / Buying Checklist

1. Define the workload and the outcome

• Name the services or jobs that must run: for example, build cache, file sharing, backup replication, virtual machines, or administrator access. Separate experiments from systems that hold unique data.
• Write one desired outcome and how it will be measured: shorter completion time, more usable capacity, a supported interface, or a recovery requirement. A headline specification alone is not an outcome.
• Record the operating system and version, concurrent users or jobs, software requirements, and the components that cannot be changed.
• Set a total-cost ceiling that includes required memory, cables, adapters, power supplies, batteries, support, electricity, and replacement parts. Reuse compatible equipment when it meets the requirement.

Workload and desired outcome:

Constraint and cost ceiling:

2. Measure the bottleneck before choosing hardware

• Record a baseline using a representative job and repeatable conditions. Note the software version, input size, cache state, and competing work.
• Look at CPU, memory pressure, storage activity, network negotiation, and errors while the problem occurs. A slow file copy can be limited by storage or protocol overhead rather than the switch.
• For Docker builds, inspect cache usage and separate cold from warm builds. Fix unnecessary cache invalidation before attributing all delay to the SSD.
• For networking, map every link between the endpoints. Check negotiated speeds and error counters before replacing a cable or assuming a new switch will help.
• Define the post-change comparison in advance. If there is no plausible link between the observed bottleneck and the proposed component, stop and collect more evidence.

Baseline, conditions, and evidence:

3. Verify interfaces, clearance, and software support

• Match the exact model and revision, not only the family name. Confirm connector, interface, lane count, supported speed, driver, firmware, and operating-system support in official documentation.
• Check physical dimensions: M.2 key and length, heatsink height, drive bays, card length, adjacent slots, cable bend space, and airflow. Do not assume every M.2 socket supports the same devices.
• Check shared resources such as PCIe lanes, SATA ports disabled by an M.2 slot, USB-controller bandwidth, switch uplinks, and power connectors.
• For memory, verify the CPU, motherboard, firmware, and module combination. Do not infer ECC support or memory limits from a product-family name.
• For FIDO SSH keys, verify both authenticator firmware and a FIDO-enabled OpenSSH build. A recent version number alone does not establish support; Apple’s bundled client is not the FIDO-enabled Homebrew build.

Exact model, interface, and clearance evidence:

4. Budget usable capacity, endurance, and expansion

• Estimate the current working set, measured growth, temporary files, snapshots, and free-space margin. Advertised disk capacity is not the same as usable capacity after redundancy and filesystem overhead.
• Choose the storage layout and failure tolerance before the drives. Check exact recording technology, controller support, sector format, cooling, and the replacement or resilver plan.
• Compare endurance and warranty at the same capacity. TBW is part of warranty terms, not a promise of a precise failure point or immunity from other faults.
• Keep a SLOG or L2ARC off the default shopping list. Add either only when measured synchronous-write or read-cache behavior justifies the device and its failure tradeoffs.
• Confirm the expansion path and its constraints. A spare bay, socket, or port does not automatically mean an existing pool or platform can grow without a migration.

Usable capacity, growth, and expansion plan:

5. Plan power, failure handling, and recovery

• Measure the complete protected load, including storage, switch, router, and dependent systems. Check both UPS watt and VA limits and the manufacturer’s runtime curve at the measured load.
• Leave room for battery aging, temperature, startup behavior, and shutdown variability. Neither a fixed sizing multiplier nor the displayed battery percentage guarantees usable runtime.
• Confirm the UPS data interface, exact NUT driver support, battery-backed outlets, and replacement-battery support before purchase.
• Map service dependencies and shutdown ordering. In a NUT primary/secondary setup, secondaries begin shutdown and disconnect before the primary finishes its wait and shuts itself down. Host Sync is a timeout, not proof that every client completed shutdown.
• Maintain an independent backup and test a restore. Redundancy, a UPS, and ECC address different failure modes; none is a substitute for a recovery copy.
• For administrative access, enroll and test an independent recovery credential before disabling a working login method. Keep console access available during authentication changes.

Measured load, shutdown test, and recovery route:

6. Check the seller, warranty, and complete cost

• Verify that the listing’s model, capacity, connector, regional variant, and included accessories match the requirement. Search-result photos and grouped variants are not enough.
• Read the applicable warranty, endurance limits, return window, exclusions, and who handles service. Confirm whether coverage applies in the destination region and to the listed seller.
• For used or refurbished equipment, establish condition, known usage, support status, replacement-part availability, and the return path. Unknown history is a risk, not a measured reliability result.
• Record required extras and ongoing operating cost before comparing alternatives. An adapter, battery, memory kit, or support dependency can change the decision.

Warranty, return route, and complete cost:

7. Do not buy yet if any stop condition applies

• The workload or bottleneck is still unclear, or a configuration or cache change has not been tried.
• The exact interface, driver, firmware, clearance, power requirement, or seller variant cannot be confirmed.
• The proposal adds capacity without a backup, restore, or failure-handling plan.
• The expected benefit depends on a claimed test, runtime, stock level, rating, or personal recommendation that lacks supporting evidence.
• The purchase removes the only working administrative access or creates a new single point of failure without recovery.
• The complete cost exceeds the ceiling, or existing hardware can satisfy the requirement after a measured adjustment.

A useful next step is to gather the missing measurement or ask a focused compatibility question. Waiting for evidence is a valid result of this checklist.

8. Record the decision and the post-change plan

Decision: reuse / defer / buy:

Candidate and evidence that it fits:

Acceptance measurement and rollback plan:

Keep this worksheet with the build notes. If sharing it publicly, remove serial numbers, personal contacts, credentials, internal hostnames, private addresses, and confidential workload data.

Compare the existing buying paths when the requirements are clear, or ask a question in the moderated discussion. No purchase or signup is required.