The homelab asset & service inventory

This is Chapter 1 of The Homelab Ops Handbook, published free and in full. It is the chapter every other chapter reads from — so it is also the one that is worth having whether or not you ever buy the book.

Homelabs fail their owners in a specific, boring way: something breaks, and the person trying to fix it doesn't remember what depends on what, where the data actually lives, or whether the thing was ever backed up in the first place. That's not a skills gap — it's a documentation gap. This worksheet is the fix: one place that answers "what do I have, and what does it need" before you're answering it under pressure.

The backup chapter's per-service table, the disaster-recovery tiers, the monitoring coverage list and the patch cadence all assume this inventory exists and is current. Fill it in first. You can't recover, monitor or patch what isn't written down anywhere.

Fill this in when…

• You're setting up this system for the first time — start here, everything else references it.
• You add any new host, VM, container or service.
• You retire or decommission anything.
• It's been a quarter since the last full review. Pair it with the backup restore drill: same cadence, same sitting.

This isn't meant to be exhaustive on day one. A rough pass with gaps you'll fill in later beats a perfect inventory you never finish starting.

1. Hardware inventory

Physical (or cloud-hosted-as-if-physical) devices, one entry per box. Include hypervisor host(s), NAS or storage array, switch, router/gateway, UPS, and anything with firmware that could fail or need patching.

Three narrow tables beat one wide one — you can fill them across a sitting or two:

| Device | Role             | Make / model | Location |
|--------|------------------|--------------|----------|
| pve01  | hypervisor host  |              |          |

| Device | Serial / asset tag | Purchased | Warranty until |
|--------|--------------------|-----------|----------------|
| pve01  |                    |           |                |

| Device | Notes |
|--------|-------|
| pve01  |       |

The warranty column earns its place the first time a disk dies and you find out you could have had it replaced for free.

2. Virtualization / hosting layer

Every VM and container, and what it runs on.

| VM / container | Purpose | Runs on (host) | OS / image |
|----------------|---------|----------------|------------|

| VM / container | Tier  | Depends on |
|----------------|-------|------------|
|                | 1/2/3 |            |

Tier is 1 = critical, 2 = important, 3 = nice-to-have. Assign it here, once. Every other procedure — what gets backed up how often, what gets monitored, what gets recovered first — reads this column instead of re-deciding it in the middle of an outage.

3. Service inventory

Every application you actually use, independent of which VM or container it lives on. This is the row that gets checked against your backup and monitoring setup.

| Service | Purpose | Runs on | Data location |
|---------|---------|---------|---------------|

| Service | Backed up? | Monitored? | Public-facing? |
|---------|------------|------------|----------------|
|         | Y/N        | Y/N        | Y/N            |

| Service | Owner |
|---------|-------|

"Public-facing" means reachable from outside your network in any way — reverse-proxied, port-forwarded, or via a tunnel. Those rows get extra scrutiny when you review credentials and when you plan for a network outage.

Any row with "Backed up? N" or "Monitored? N" is a decision, not an accident. Either bring it into scope, or write down in Notes why it's deliberately excluded — a throwaway test VM, for example. An undecided gap is the thing that bites you.

4. Network segments

Document the purpose of each segment, not the literal addressing — this is a document you might share, hand to someone else, or keep somewhere less private than you think.

| Segment / VLAN purpose            | What lives here | Isolated from                   |
|-----------------------------------|-----------------|---------------------------------|
| Management (hypervisor/host admin)|                 | Everything except your admin box|
| Trusted / general lab             |                 |                                 |
| IoT / untrusted devices           |                 | Trusted segment                 |
| Guest                             |                 | Everything else                 |
| DMZ / public-facing services      |                 | Internal segments               |

If you have one flat network today, that's fine — write "flat, no segmentation" as a row and treat segmentation as a future hardening project, not a prerequisite.

5. Credential & access map — pointers only

This worksheet never contains real passwords, keys or tokens. It documents where they live, so you (or whoever is standing in for you) can find them.

| What                             | Where it's stored       | Who has access |
|----------------------------------|-------------------------|----------------|
| Password manager (master vault)  | [tool name]             |                |
| Hypervisor/NAS admin credentials | [password manager entry]|                |
| Backup target credentials        | [password manager entry]|                |
| SSH keys                         | [location]              |                |
| Router/gateway admin             | [password manager entry]|                |

6. Dependency map

A short narrative, not another table. Write what depends on what, in your own words. This is what makes a recovery order-of-operations specific to your lab instead of a generic sequence:

Network (router/switch) -> local DNS -> storage pool -> hypervisor host ->
auth/reverse proxy -> [everything else, in whatever order you actually use it]

Write yours. The point of the exercise is discovering the link you'd have forgotten — the one where your password manager is behind the reverse proxy that needs the DNS that runs on the hypervisor you're trying to log into.

7. Review cadence

• New service, VM or hardware: add its row the same day, not "I'll do it later".
• Quarterly full review, same sitting as the backup restore drill.
• Decommissioned anything: remove its row here, and confirm it's also out of backup scope and monitoring. An orphaned backup job for a service that no longer exists is a quiet source of wasted storage and false confidence.

Two copy-paste checklists

New-service onboarding

Service: __________
1. [ ] Added to the service inventory table
2. [ ] Tier assigned (1/2/3) and dependency noted
3. [ ] Added to backup scope
4. [ ] Added to monitoring coverage
5. [ ] Credentials stored in the password manager, not in a config file or note app
6. [ ] If public-facing: reviewed against your access-hygiene checklist

Decommission

Service/device: __________
1. [ ] Removed from the service/hardware inventory
2. [ ] Backup job disabled; old copies retained per policy, then purged
3. [ ] Monitoring checks removed (stop alerting on something that's supposed to be gone)
4. [ ] Credentials rotated/revoked, entry removed from the password manager
5. [ ] Data migrated, or confirmed no longer needed, before deletion

That's Chapter 1 in full. The other eight chapters — the backup and restore drill, disaster recovery, monitoring, patching, access hygiene, storage health, network outage and the change log — plus 49 fill-in worksheets are in The Homelab Ops Handbook ($29 minimum / $39 suggested). Free updates forever. 30-day 100% refund, no questions.