# 0011 How My Homelab Grew Up

> Problem: Instead of discovering a problem because a service feels slow or someone tells me something is down, I can look at resource usage, uptime, logs, and host behavior from one place. Approach: The cheapest way to get a lot of compute was a used Dell C1100: two CPUs, 72 GB of memory, and enough fan noise to make the entire house aware of my choices. Outcome: The homelab works better now because responsibilities...

## Agent Digest

- Problem: Instead of discovering a problem because a service feels slow or someone tells me something is down, I can look at resource usage, uptime, logs, and host behavior from one place.
- Aaron's position: That was probably the first time I learned that infrastructure is physical before it is software.
- Approach: The cheapest way to get a lot of compute was a used Dell C1100: two CPUs, 72 GB of memory, and enough fan noise to make the entire house aware of my choices.
- Outcome: The homelab works better now because responsibilities are clearer.
- Audience fit: Best for readers and agents researching Aaron Spindler's tech writing on 0011 How My Homelab Grew Up.
- Why it matters: How My Homelab Grew Up My homelab did not start with Kubernetes, dashboards, or a carefully planned rack diagram.
- Best for:
  - Understanding the main argument of 0011 How My Homelab Grew Up.
  - Finding citable details from Aaron's tech writing.
  - Answering questions about How My Homelab Grew Up.
  - Answering questions about TL;DR.
  - Answering questions about Mining.
- Not for:
  - Authoritative third-party documentation.
  - A complete substitute for the canonical article body.
- Core claims:
  - That was probably the first time I learned that infrastructure is physical before it is software. (How My Homelab Grew Up)
  - The community era made uptime visible because other people were using the services. (TL;DR)
  - AMD HD 7970 mining rigs turn one gaming PC into a lesson about power, heat, uptime, and dirty real-world environments. (Mining)
- Evidence:
  - My homelab did not start with Kubernetes, dashboards, or a carefully planned rack diagram. (How My Homelab Grew Up)
  - It started in 2012 with a gaming computer, an AMD HD 7970, and the kind of curiosity that makes a teenager ask a dangerous question: what if this machine just ran all the time? (How My Homelab Grew Up)
  - Eventually there were more than six four-GPU systems running in my dad's warehouse, where power was effectively included with the lease. (How My Homelab Grew Up)
  - That was probably the first time I learned that infrastructure is physical before it is software. (How My Homelab Grew Up)
- Caveats:
  - My homelab grew in eras: mining taught physical constraints, game servers made reliability social, Plex made the hardware useful to my family, UniFi made the network part of the platform, Home Assistant made the house programmable, and Proxmox, TrueNAS, Dokploy, Cloudflare, monitoring, Git, and code agents turned it... (TL;DR)
  - The warehouse moved the noise somewhere else, but it introduced harder lessons. (Mining: The First Always-On System)
  - The mining era was messy, but it gave me the first real taste of running systems that did not get to shut off just because I was done using them. (Mining: The First Always-On System)
  - I wrote more about that early community-server era in my career timeline, but the homelab lesson was simple: real users make uptime real. (Game Servers And Real Users)

## Metadata

- Canonical URL: https://aaronspindler.com/b/tech/0011_How_My_Homelab_Grew_Up/
- Markdown URL: https://aaronspindler.com/b/tech/0011_How_My_Homelab_Grew_Up/index.md
- JSON URL: https://aaronspindler.com/b/tech/0011_How_My_Homelab_Grew_Up/index.json
- Category: tech
- Published: 2026-07-08T12:49:58+00:00
- Updated: 2026-07-08T16:58:36.252241+00:00
- Word count: 3109
- Content hash: f5fde98c330800e0534f13b654cd9eae04d88461628f986246638be98128de88
- AI written: no
- Format version: agent-blog-post-v2

## Takeaways

- That was probably the first time I learned that infrastructure is physical before it is software. (How My Homelab Grew Up)
- The community era made uptime visible because other people were using the services. (TL;DR)
- AMD HD 7970 mining rigs turn one gaming PC into a lesson about power, heat, uptime, and dirty real-world environments. (Mining)
- Minecraft, Counter-Strike: Source, Team Fortress 2, Terraria, and Teamspeak make uptime matter to a real community. (Game servers)
- A Dell C1100 with 72 GB of RAM delivers cheap compute and reliable service at the cost of noise and heat. (Enterprise hardware)
- The lab becomes something my family can actually use, not just a collection of loud machines. (Plex)

## Questions Answered

- What problem does 0011 How My Homelab Grew Up address?
- What position does Aaron take in 0011 How My Homelab Grew Up?
- How does 0011 How My Homelab Grew Up approach the problem?
- What evidence or outcomes does 0011 How My Homelab Grew Up provide?
- What does the article explain about How My Homelab Grew Up?
- What does the article explain about TL;DR?

## Agent Queries

- Aaron Spindler "0011 How My Homelab Grew Up"
- 0011 How My Homelab Grew Up tech Aaron Spindler
- 0011 How My Homelab Grew Up Instead of discovering a problem because a service feels slow or someone tells me something is down, I can look at resource usage, uptime, logs, and host behavior from one place.
- 0011 How My Homelab Grew Up How My Homelab Grew Up
- 0011 How My Homelab Grew Up TL;DR

## Follow-Up Questions

- What changed after the approach in 0011 How My Homelab Grew Up was applied?
- What tradeoffs or constraints remain after 0011 How My Homelab Grew Up?
- What setup is required before applying the ideas in 0011 How My Homelab Grew Up?
- How would How My Homelab Grew Up change in a different environment?

## Outline

-   How My Homelab Grew Up
-   TL;DR
-     Mining
-     Game servers
-     Enterprise hardware
-     Plex
-     UniFi
-     NAS and VMs
-     Home Assistant
-     Private cloud
-   Mining: The First Always-On System
-   Game Servers And Real Users
-   Plex Made It Legible
-   The Network Became Infrastructure
-   From Spare Machines To A Small Cluster
-   Home Assistant Made The House Programmable
-   Dokploy And The Private Cloud Arc
-   From Vibes To Signals
-   Git History For The House
-   The Current Shape
-   What Changed

## Body

## How My Homelab Grew Up

My homelab did not start with Kubernetes, dashboards, or a carefully planned rack diagram. It started in 2012 with a gaming computer, an AMD HD 7970, and the kind of curiosity that makes a teenager ask a dangerous question: what if this machine just ran all the time?

At first that meant Bitcoin mining from my bedroom. Then one GPU became more GPUs. One machine became several machines. Eventually there were more than six four-GPU systems running in my dad's warehouse, where power was effectively included with the lease. It was clever until the warehouse reminded me it was not a clean data center. Dust, metal shavings, dirty power, heat, noise, and failing hardware all became part of the lesson.

That was probably the first time I learned that infrastructure is physical before it is software. A service is not just a process. It is power, airflow, cables, fans, storage, dust, the room it lives in, and whoever else has to tolerate it.

## TL;DR

My homelab grew in eras: mining taught physical constraints, game servers made reliability social, Plex made the hardware useful to my family, UniFi made the network part of the platform, Home Assistant made the house programmable, and Proxmox, TrueNAS, Dokploy, Cloudflare, monitoring, Git, and code agents turned it into a small private cloud and home operations platform.

- The early lesson was physical: always-on hardware creates heat, noise, dust, and failure modes.
- The community era made uptime visible because other people were using the services.
- The useful-service era started when Plex gave the homelab a clear purpose beyond tinkering.
- The current era is more production-minded: repeatable config, monitoring, safer access, and real hosted services.
- It is still not finished. The storage layer is the part I most want to make more resilient.

The timeline is not perfectly chronological. A homelab rarely grows in a straight line. It grows at pressure points: when something breaks, becomes useful, gets annoying, or starts mattering to someone other than you.

1. 2012 Mining AMD HD 7970 mining rigs turn one gaming PC into a lesson about power, heat, uptime, and dirty real-world environments.
2. 2012-2014 Game servers Minecraft, Counter-Strike: Source, Team Fortress 2, Terraria, and Teamspeak make uptime matter to a real community.
3. Early lab Enterprise hardware A Dell C1100 with 72 GB of RAM delivers cheap compute and reliable service at the cost of noise and heat.
4. Useful Plex The lab becomes something my family can actually use, not just a collection of loud machines.
5. Network UniFi Cheap routers stop being enough, and the network becomes part of the homelab control plane.
6. Storage NAS and VMs Spare mining and gaming hardware turns into storage, file sharing, VM hosting, Plex, game servers, and Frigate.
7. 2022 Home Assistant After buying a house, automation slowly moves from dashboard tinkering into daily routines.
8. Now Private cloud Proxmox, tiny PCs, TrueNAS, Dokploy, Cloudflare, monitoring, Git, and agents turn the lab into something closer to a small production platform.

## Mining: The First Always-On System

![Open Desktop PC Tower Interior](https://api.photonfolio.com/api/v1/photonfolio/public/embeds/a393f81a-f897-4d24-bf0e-430071b22a87/image/) ![Custom PC Tower on Wooden Table](https://api.photonfolio.com/api/v1/photonfolio/public/embeds/4c074d8d-0b38-4749-8ad0-ecd54a376b88/image/) Mining started as one desktop and grew into dedicated always-on machines.

The Bitcoin mining phase was not elegant. It was consumer hardware doing server-shaped work. The first card ran in my gaming computer, which immediately made heat and noise impossible to ignore. The room got hotter. The fans got louder. The machine needed attention.

Then it grew: more GPUs, more machines, more 24/7 runtime. The warehouse moved the noise somewhere else, but it introduced harder lessons. Dust got everywhere. Metal shavings were a real concern. Dirty power created weird failure modes. Debugging became environmental, not just software.

That was useful. Not comfortable, but useful. It made the invisible parts of infrastructure obvious. Power quality matters. Airflow matters. Physical placement matters. A system that is stable for a gaming session is not automatically stable for weeks of continuous load.

That lesson still shows up in the current homelab. I care about power draw now. I care about heat. I care about whether a service is worth the operational burden it creates. The mining era was messy, but it gave me the first real taste of running systems that did not get to shut off just because I was done using them.

![Stacked Graphics Cards on Workbench](https://api.photonfolio.com/api/v1/photonfolio/public/embeds/3ceaa9d3-0bd4-4ca6-84d6-f8ac8f650720/image/)

## Game Servers And Real Users

My first real "production" users came from gaming, not work. I started with Minecraft because I wanted my own world and my own rules. Then I wanted better plugins, better uptime, better performance, and a server that did not vanish every time I took my MacBook out of the house.

That eventually led me to retired enterprise hardware. The cheapest way to get a lot of compute was a used Dell C1100: two CPUs, 72 GB of memory, and enough fan noise to make the entire house aware of my choices. It was fast, reliable, and wildly inappropriate for a normal room. It was also a great teacher.

![Home Server Rack in a Windowed Room](https://api.photonfolio.com/api/v1/photonfolio/public/embeds/2471e27e-73ef-4c0d-8398-6bc7e4065d60/image/) ![Home Computer Equipment Room](https://api.photonfolio.com/api/v1/photonfolio/public/embeds/71eb3390-fd08-48fe-94cf-89e41e48f6c2/image/) The game-server years made the room itself part of the system: rack gear, heat, fans, and cables.

The game server era grew beyond Minecraft. I ran Counter-Strike: Source, Team Fortress 2, Terraria, and Teamspeak. Falcon Gaming came out of that world too. I had been part of other gaming communities that slowly fell apart because the leadership was flaky or the infrastructure stopped being dependable. I wanted to build somewhere more stable.

That changed the stakes. If the server was slow, people complained. If Teamspeak was down, people noticed. If a game server crashed, it was not an abstract failure on a dashboard. It interrupted whatever people were doing together.

I wrote more about that early community-server era in my [career timeline,](https://aaronspindler.com/b/personal/0010_Career_Timeline/#early-spark) but the homelab lesson was simple: real users make uptime real. You can tell yourself something is just a hobby until other people depend on it. Then reliability becomes part of the feature set.

## Plex Made It Legible

Plex was running around the same time as the gaming services, but it played a different role. Game servers made the homelab useful to friends and online communities. Plex made it useful to my family.

That mattered. Up to that point, a lot of the lab looked like an electric hurricane in my room. Machines were on all the time. Fans were loud. Heat was real. Plex gave me something concrete to show my parents and brother. This is what the hardware does. This is why it is running. This is not just noise for the sake of noise.

That changed how I thought about the lab. It was not enough for something to be technically interesting. The best services earned their place by being used. Plex was one of the first services that felt durable because it had a simple, visible value: people could watch things without caring about the messy infrastructure behind it.

That is still one of my filters. A homelab can absorb infinite complexity if you let it. The question is whether that complexity pays rent. Plex did. A lot of experiments did not.

## The Network Became Infrastructure

![Network infrastructure](https://api.photonfolio.com/api/v1/photonfolio/public/embeds/dd756532-1da6-4306-bff7-32f5a8bf6902/image/)

For a while, the network was whatever the ISP or a cheap Linksys router could tolerate. Eventually that stopped working. The routers would just fall over. Wi-Fi performance and range were poor. Administrative control was almost nonexistent.

That was the point where networking stopped being a background utility and became part of the homelab. The first UniFi gear I bought was a UniFi Security Gateway. Since it was just a wired router, I also had to add access points and switching to make the whole setup usable.

The immediate win was control: visibility, management, and a network I could reason about instead of something I rebooted when it misbehaved.

I am deliberately keeping the network details high-level here. The important part is not the exact topology. It is the shift in mindset. Once you run services at home, the network is not separate from the application. It is the path users take to everything else. If the network is unreliable, the whole homelab feels unreliable.

## From Spare Machines To A Small Cluster

When GPU mining stopped being profitable for me, it left behind a lot of still-useful hardware. Those old mining machines and decommissioned gaming parts became the next stage of the homelab. Instead of buying purpose-built infrastructure, I repurposed what I already had.

The old gaming machine became a storage and VM host. At different points, that class of hardware ran game servers, Plex, NAS workloads, file sharing, and Frigate. It was a practical bridge between the loud enterprise server era and the more intentional setup I have now.

The current storage layer is still built around old personal hardware: TrueNAS on my old gaming machine with an i7-3930K, 32 GB of RAM, five 10 TB hard drives, and a 512 GB SSD cache. It works, and it has been useful, but it is also the part of the system I trust the least from a resilience perspective. There is still a single point of failure there that I want to remove.

Compute has moved in a different direction. Instead of one bigger box doing everything, the lab now uses a distributed set of tiny PCs managed by Proxmox. They handle almost everything except storage. The appeal is straightforward: more compute, better failover options, less power, and cleaner separation between roles.

Frigate also changed the hardware mix. Camera processing made acceleration matter, and that eventually led to a macOS device in the homelab so I could use the NPU and GPU on an M4 chip. That is a very homelab kind of outcome: one workload exposes a constraint, and suddenly the architecture shifts around it.

## Home Assistant Made The House Programmable

Home Assistant entered the picture when I bought my house in 2022. At first it sat quietly in the background with hand-designed automations and dashboards. It was useful, but it had not yet become central.

The automation that made it feel real was my morning routine. When I press a button on my nightstand, or when my phone exits sleep mode, the house starts moving with me. The espresso machine turns on and starts heating. The sound machines throughout the bedrooms turn off. The bathroom light comes on dimly. Heating or cooling adjusts depending on the season and the temperature outside.

Morning automation flow Trigger Nightstand button or phone exits sleep Home Assistant One routine fans out into the house Espresso heats Sound machines stop Bathroom light turns on dimly Climate adjusts

That is the kind of automation that changes how you think about the system. It is not a dashboard anymore. It is part of a daily rhythm. The house becomes programmable in a way that is useful, not theatrical.

It also creates new reliability concerns. My current Home Assistant setup still has a weakness: I use a USB Zigbee antenna, which means the VM is effectively tied to a specific Proxmox host. It does not fail over cleanly the way I would like. That is not catastrophic, but it is exactly the kind of constraint that starts bothering you once the automations become part of normal life.

That is another recurring homelab pattern. A setup can be perfectly acceptable when it is an experiment and suddenly feel fragile when it becomes part of the house.

## Dokploy And The Private Cloud Arc

The hosted-services side of the homelab went through its own maturity curve. CapRover was useful for a while because it made self-hosting apps feel approachable. But over time it became harder to trust. I ran into random hiccups that could lock up everything on the VM. Scaling horizontally was not pleasant. DNS validation did not play nicely with Cloudflare. Basic features needed workarounds.

At some point familiarity stopped being a good reason to keep it. Dokploy replaced that layer and became the foundation for hosting my own cloud services. Today it hosts public-facing projects like Photonfolio, Spindlers, AaronSpindler, and Repotopo.

That shift matters because the homelab is not only serving internal tools now. Some of the things running on it are live services. That raises the standard: not just making something work on my LAN, but making it recoverable, understandable, and boring enough to trust.

Cloudflare is a big part of the current architecture. Tunnels give me easy access and tight control without opening public inbound connections into my local network. No port forwarding, less pressure on the UniFi firewall, and fewer exposed edges. The goal is not to pretend the homelab is the same as a cloud region. It is to be honest about what is running at home and put a controlled access layer in front of it.

Access path Public DNS Visitors reach hosted project domains Cloudflare Policy, TLS, and tunnel entry Tunnel Outbound connection from home Dokploy apps Services stay on local hosts The important boundary is directional: public entry lives at Cloudflare; home services connect out.

## From Vibes To Signals

Monitoring is the line between "I think it is fine" and "I can see what is happening." The current homelab has crossed that line.

I use the monitoring stack to keep track of tools hosted across Proxmox, self-hosted GitHub Actions runners, uptime across local and public services, and a central place for logs. The names are familiar: Grafana, Uptime Kuma, Alloy, Prometheus, Loki, UniFi, and Frigate all play a part.

Signals loop Systems Hosts, apps, network, cameras Signals Metrics, uptime, logs, events Views Grafana, Kuma, Loki, Frigate Action Fix, simplify, remove, document feedback to systems Feedback from action returns to systems.

That does not mean everything is perfect. It means failures are less mysterious. Instead of discovering a problem because a service feels slow or someone tells me something is down, I can look at resource usage, uptime, logs, and host behavior from one place. The homelab becomes less dependent on memory and vibes.

This era also includes experiments that did not survive. A local artifact cache and Nexus-apt setup were useful ideas. I wanted faster, more controlled dependency and package flows. But the operational complexity was too high for the value I was getting. Removing something is not failure if it leaves the system clearer.

That is a lesson I keep relearning. A homelab is a great place to try production patterns, but not every production pattern belongs at home. Sometimes the right move is to delete the clever thing.

## Git History For The House

The private repo that manages the homelab exists for three reasons: reproducibility, visibility for agents, and history.

Manual configuration works when the system is small. Click something in a UI, change a value, restart a container, move on. But eventually the question becomes uncomfortable: what changed, why did it change, and could I rebuild this if I had to?

Putting more of the homelab into Git gives me a better answer. It creates a record. It gives code agents something inspectable. It makes reviews and diffs possible. It also forces me to decide what should be treated as configuration, what should stay private, and what should be documented enough that future me can recover it.

Agents now help with a lot of the work around the edges: debugging, investigation, tinkering, docs, validation, upgrades, service maps, and Home Assistant changes. They are not the main character of the homelab story, but they changed what feels maintainable. A repo-managed homelab is much easier to reason about when an agent can inspect the shape of the system, propose a narrow change, and leave a history trail.

That does not remove judgment. It raises the value of good boundaries. Secrets stay secret. Network details do not need to be public. Validation matters. The point is not to automate recklessly. The point is to make repeatable work more repeatable.

## The Current Shape

![Network Equipment Rack in Cabinet](https://api.photonfolio.com/api/v1/photonfolio/public/embeds/631ee3a7-21a5-4799-912d-afb25c33c6da/image/)

The current homelab is a blend of small private cloud, home operations platform, and learning lab. That sounds grander than it feels day to day. In practice, it is a collection of systems that each earned their place because they solve a real problem.

Current system map Access Cloudflare tunnels and DNS Network UniFi routing, wireless, and switching Compute Proxmox-managed tiny PCs Storage TrueNAS and persistent data Apps Dokploy and hosted services Home ops Home Assistant and Frigate Observability Metrics, uptime, logs, and cameras Control plane Git, validation scripts, and code agents

| Layer | Role | Examples |
| --- | --- | --- |
| Access | Controlled public and remote entry points | Cloudflare tunnels and DNS |
| Network | Home routing, wireless, and service connectivity | UniFi |
| Compute | Distributed service hosts | Proxmox-managed tiny PCs |
| Storage | Central persistent data layer | TrueNAS |
| Home operations | Automation, cameras, and daily routines | Home Assistant and Frigate |
| Apps | Public and private hosted services | Dokploy, Photonfolio, Spindlers, AaronSpindler, Repotopo |
| Observability | Uptime, metrics, logs, and host visibility | Grafana, Uptime Kuma, Prometheus, Loki, Alloy |
| Control plane | Repeatable configuration and assisted maintenance | Git, validation scripts, code agents |

The table is intentionally sanitized. The useful idea is the layering, not the exact topology. The homelab works better now because responsibilities are clearer. Storage is storage. Compute is compute. Access is controlled. Monitoring is centralized. Configuration has history.

## What Changed

Maturity ladder Possibility Could I host this? Dependence Other people use it. Operation I can observe and recover it. Resilience I am designing out fragile center points.

The biggest change is that I no longer think of the homelab as a pile of services. I think of it as an operated system.

That does not mean it is enterprise-grade. It means I am applying more of the same instincts I would bring to production work: make it observable, reduce weird manual state, document enough to recover, keep access controlled, and remove things whose complexity no longer pays for itself.

The old homelab optimized for possibility. Could I host this? Could I make that work? Could I squeeze one more service onto this box? The current homelab optimizes for recoverability and uptime. I am hosting real services now, so the architecture has to make those goals realistic.

There is still a lot to improve. The storage layer is the obvious one. Right now it is too central and not resilient enough. If I were building it again from scratch, I would design storage redundancy earlier instead of letting one machine become the center of gravity.

That is probably the most honest place to end this version of the story. The homelab grew up, but it is not finished. It keeps changing because the constraints keep changing. A new workload appears. A service becomes important. A tool gets too fragile. A failure mode becomes visible. The next iteration comes from there.

So the open question is the same one that started the whole thing, just with better judgment now: what should I try next?

## Links

- [career timeline,](https://aaronspindler.com/b/personal/0010_Career_Timeline/#early-spark) (internal)

## Related Posts

- [0010 Career Timeline](https://aaronspindler.com/b/personal/0010_Career_Timeline/)