Why I Built a Server in My Living Room: Homelab Beginnings

My friends thought I was eccentric. And they weren't entirely wrong.

It was August 2019, and I'd just finished repurposing an old gaming desktop - a machine that had served its time as a gaming rig - into something far more useful. The GPU that once drove games now had company: additional graphics cards and a stack of hard drives bolted on, the whole machine running GPU compute workloads around the clock while I slept. But tucked alongside that compute cluster was the beginning of something different: actual server infrastructure.

The setup looked absurd next to my couch. LEDs blinking in the dark. Ethernet cables snaking across the floor. A small appliance that consumed more electricity than my refrigerator.

"Why not just use cloud services?" a colleague asked. "Why build this thing?"

Good question. The honest answer: Corporate environments limit what you can learn. So I built a lab where nothing was off-limits.

The Context: Why Constraint Breeds Restriction

By August 2019, I'd just started a new role at a global pharmaceutical manufacturer - an Automation Engineer position inside a pharmaceutical manufacturing plant. GxP compliance, DeltaV systems, Siemens automation, regulatory-grade documentation. Serious, high-stakes work.

It was interesting. But there were constraints:

Technical constraints:

Limited to established tech stack (DeltaV, Siemens systems, corporate databases)
Can't experiment with new technologies without approval cycles
Testing is risky-failures impact production systems
Innovation is limited to "approved" paths

Process constraints:

Change management for everything (understandable in pharma, but slow)
Security requirements limit network experimentation
Compliance frameworks prevent "unauthorized" tools
Learning happens within corporate boundaries

Organizational constraints:

I'm one person in a large organization
Budget for R&D is allocated and inflexible
New ideas need stakeholder alignment
Experimentation requires justification to multiple parties

These constraints make sense. Medical device manufacturing should be conservative. If your automation system fails, patients could be harmed. Regulatory compliance requires proof that everything is tested and validated.

But they also mean you can't learn freely. You're learning within a narrow path.

The Realization: Constraint Breeds Restriction

In corporate environments, you learn what the organization needs you to learn. Valuable? Yes. But incomplete.

What if I wanted to learn:

Docker containerization (not used in pharma manufacturing)
Kubernetes orchestration (way too experimental for GxP systems)
IoT workflows (interesting but not relevant to current role)
VPN and network segmentation (security relevant, but not tested in my environment)
Self-hosted automation tools (like n8n-not approved)
Streaming infrastructure (media server concepts not applicable to pharma)

None of these were bad to learn. But none would be approved for my corporate environment. So if I wanted to learn them, I had to build my own space.

Hence: homelab.

Not as a distraction from work. Not as a side project. But as a personal R&D lab where ideas could be tested freely.

The Initial Setup: Starting Simple, Expanding Methodically

I didn't build a production-grade infrastructure on day one. I started with a specific goal: learn Docker and self-hosting.

Month 1: Plex Media Server

Plex was the obvious starting point - mature, widely documented, with a UI that actually worked. Not exactly rocket science. But it taught me:

How to use Linux on non-standard hardware
Basic networking (port forwarding, exposing services)
File organization and access permissions
Database basics (Jellyfin uses SQLite backend)

The learning: I could build something useful that wasn't cloud-dependent.

Month 2-3: Expanding Services

Adding services beyond Jellyfin:

File server (understanding storage and permissions)
DNS configuration (understanding local network naming)
VPN setup (understanding secure remote access)
Basic monitoring (observing resource usage)

Each service added a new technical concept. Nothing too advanced, but each one required learning.

Month 4-6: Docker Containerization

This was the shift. Instead of installing services directly on the OS, I containerized everything:

Each service in its own container
Docker compose for orchestration
Volume management for persistence
Network isolation between services

This taught me:

Container concepts (used at work for medical device deployments)
Infrastructure as code thinking (applicable everywhere)
Separation of concerns at infrastructure level

Month 7-12: Adding Automation

By end of 2019, the stack had grown meaningfully:

Node-RED for IoT and workflow automation - visual flow-based programming that made it easy to wire together triggers and actions
Pi-hole for network-level DNS filtering and ad blocking - which also taught me how DNS resolution actually works at the network layer
Nextcloud for self-hosted file sync and storage - a personal Dropbox that kept my data off third-party servers
Basic workflow orchestration connecting all of the above

These taught me automation at a different level-not just business processes, but infrastructure automation.

The Critical Insight: Lab ≠ Distraction

Here's what people don't understand about hobbies: they're not distractions if they're in the same domain as your work.

If I were building hobbies unrelated to my job (woodworking, sports, gaming), these would be distractions. Separate activities competing for time.

But homelab is infrastructure learning. Everything I build here is directly applicable to my corporate role.

For example:

Docker learning → Corporate application: By 2021, medical device deployments began using Docker containers. I'd already built a containerized system at home. I knew pain points, architecture decisions, failure modes. Advantage: One year of practical experience before corporate work required it.

VPN and network segmentation → Corporate application: Secure access to systems in different countries requires network architecture thinking. I'd designed my own VPN infrastructure at home. Advantage: Already knew the concepts and implementation challenges.

Monitoring and observability → Corporate application: Building dashboards that show what's happening in systems is critical at enterprise scale. I'd built monitoring for my homelab. Advantage: Understood what metrics matter, what causes problems, how to visualize them.

Automation workflows → Corporate application: At a global medical aesthetics and technology company, I built the 70% RMA automation system. The core concepts were tested in my homelab years earlier. Advantage: Knew what works, what doesn't, how to structure systems for reliability.

Every single major corporate achievement has roots in something I learned in the homelab first.

This isn't coincidence. It's deliberate: build ideas at home scale, then deploy at enterprise scale.

The Philosophy: Personal R&D Lab

Corporate environments are where you apply knowledge.

Homelabs are where you explore knowledge.

This distinction is critical. In corporate:

Time pressure (deliver features/fixes fast)
Reliability requirements (downtime is bad)
Compliance constraints (approved tools only)
Learning is secondary (getting work done is primary)

In homelab:

Time is flexible (failure is learning)
Reliability is optional (break things on purpose)
No constraints (try anything)
Learning is primary (getting work done is secondary)

Most people do this backwards. They learn at work and experiment at home. I do the opposite: experiment at home and apply at work.

Because corporate experiments are expensive. You're paying salary while people learn. You're risking production systems. You're consuming budget on experiments.

But home experiments are free. My electricity cost is negligible. My time is my own. Failure teaches something.

So I experiment at home, validate approaches, then bring proven ideas to work.

This is exactly what happened with the n8n workflow that eliminated 70% of RMA manual work.

I built n8n workflows at home first. Tested them. Broke them intentionally. Refined them. Only when I knew they worked reliably did I propose the idea at work.

By the time I presented it to management, I already had:

Proof of concept (working at home)
Understanding of failure modes (learned through breaking it)
Reliability strategy (tested in production)
Documentation (built while experimenting)

This made implementation at work trivial. Six weeks from proposal to full regional deployment because all the learning had already happened.

The Setup: What a Homelab Looks Like

By mid-2019, the basic setup included:

Hardware: Repurposed 980Ti gaming desktop, supplemented with additional GPU cards and a bank of hard drives for compute workloads running parallel to the homelab services

Services:

Plex: Media management and streaming
Nextcloud: Self-hosted file sync and personal cloud storage
Pi-hole: Network-level DNS filtering and ad blocking
Node-RED: Automation workflow orchestration
Docker: Containerization for all of the above
Tailscale: Zero-config VPN mesh for secure remote access
Caddy: Reverse proxy with automatic HTTPS via Cloudflare

Architecture:

Network segmentation (separate network for experimental services)
Backup strategy (local + cloud)
Power management (UPS for stability)
Monitoring (alerting for problems)

Time investment:

Initial setup: ~40 hours (sourcing, building, configuring)
Monthly maintenance: ~5 hours
Learning projects: Variable (4-10 hours per experiment)

The Mindset: Breaking Things on Purpose

The most important part of a personal lab is the freedom to fail.

In my homelab, I deliberately break things:

Deploy updates and watch what breaks
Shut down services and observe dependencies
Run out of storage intentionally to see error handling
Simulate network failures
Test backup restoration

Every failure teaches something. And these are cheap lessons. I lose access to media streaming for an afternoon. At work, a similar failure could cost thousands in production downtime.

By learning failure modes at home, I prevent them at work.

This is why experienced engineers are valuable. Not because they know everything, but because they've broken everything. They know what hurts, what matters, what doesn't.

The homelab is where you pay the price of experience at a discount.

The Connection: Homelab → Corporate Achievement

I can trace the major accomplishments at a global medical aesthetics and technology company directly to homelab learnings:

70% RMA Automation:

Built with n8n (experimented at home)
Architecture based on patterns from homelab Docker systems
Monitoring approach copied from homelab infrastructure
Deployment process borrowed from homelab experiences

Mobile SAP Integration:

Developed as experiment at home (mobile-friendly interface problem)
Tested with homelab users first
Deployed with confidence because approach was proven

Regional Process Standardization:

Infrastructure thinking from homelab helped standardize workflows
Container thinking helped create modular processes (like modular services)
Monitoring approach helped observe process compliance across regions

None of these would have happened the same way without the homelab. I would have been learning on corporate dime, with risk to production systems, under time pressure.

Instead, I learned at home, validated the approach, then brought proven methodology to work.

The Paradox: Hobby That Made Me Better at My Day Job

This is the weird thing about homelabs built thoughtfully:

They're hobbies that directly improve your professional work.

Most hobbies are pure recreation. They make you happy but don't make you better at your job.

Homelabs are different. They're play-based learning in your professional domain.

You're building infrastructure for fun, learning skills that happen to be exactly what you need at work.

Some colleagues would see the homelab as distraction: "Why waste weekends on servers when you could relax?"

But I don't see it as distraction. I see it as investment. I'm paying myself in knowledge, not money.

And that knowledge compounds. The Docker learning in 2019 made me more valuable in 2020, 2021, 2022, and beyond.

Reflection: Continuous Learning as Work Philosophy

Here's the bigger picture: I believe work is craft, not career.

Career is about advancing titles and compensation. Craft is about building better and better systems.

One way to practice craft is through your day job. The other is through self-directed learning.

The homelab is self-directed learning. It's where I explore ideas without corporate constraints. It's where I stay sharp between projects. It's where I validate new approaches.

Every exceptional engineer I know has some version of this-a personal lab where they practice their craft freely.

Some people call it a "side project." I call it an R&D lab. The framing matters. Side projects feel like extra work. R&D labs feel like investment in yourself.

This is post-financial-independence thinking. If you don't need the money, you can frame work differently. You can focus on craft. You can invest in learning. You can experiment.

The homelab wouldn't exist without the financial security from game automation and e-commerce. But now that it exists, it's paying dividends at work.

Everything compounds. Everything teaches something. Everything makes the next project easier.