Notes from a year of running my own homelab instead of the cloud

Twelve months ago, I spent $847 on a used Dell R720 and told myself I was done with cloud bills. Not reducing them, not optimizing them — done. I'd been running a few small projects on AWS and DigitalOcean, watching those monthly charges creep up for what felt like glorified file storage and compute I barely used. The server showed up in a box that weighed forty pounds, and I realized I had no idea what I'd actually signed up for.

The first week was quietly terrifying. I'd moved my personal website and a few Docker containers over, everything seemed fine, then I went to bed wondering what happened if something broke while I was sleeping. No support tickets, no SLA promises — just me and whatever I'd misconfigured. I kept checking my phone at weird hours, half-expecting everything to be down.

What I Actually Moved Home

The migration list got longer than I expected. The obvious stuff went first: file storage, personal backups, a Plex server I'd been meaning to set up anyway. Then I got curious about what else I could pull back. My Git repositories moved to a self-hosted Gitea instance. A small monitoring stack. CI/CD runners that had been costing me $20 a month for maybe six builds.

Email hosting turned into a three-week nightmare that I eventually gave up on. Every guide made it sound straightforward until you hit deliverability issues and realize why people pay for email services. My messages kept landing in spam folders, and debugging DKIM/SPF/DMARC configs while trying to actually get work done felt like masochism.

But other things clicked immediately. The Git server was running in fifteen minutes and felt faster than GitHub for my private repos. The media server became a weekend obsession — I started ripping old DVDs just because I could. A personal wiki for project notes. A bookmark manager. Tiny services that would've been $5-10 each in the cloud but cost me nothing incremental on bare metal.

I kept some things in the cloud longer than my ideology wanted to admit. The main database for a client project stayed on RDS because I wasn't ready to be the DBA for something that actually mattered. Static site hosting remained on Netlify because their CDN and deployment pipeline just worked better than anything I wanted to maintain myself.

The 3 AM Learning Curve

The first major failure happened during a storm in month three. My UPS was apparently more "decorative" than "functional," and when the power flickered, everything went down hard. Not a clean shutdown — just dead. I spent two hours in the basement with a flashlight, checking connections and praying I hadn't corrupted anything important.

That's when I learned about RAID rebuild times on consumer drives. And proper UPS sizing. And why enterprise hardware has redundant power supplies. Skills I definitely didn't have on my résumé but suddenly needed at midnight on a Tuesday.

The debugging sessions were different from anything I'd experienced in the cloud. When something breaks on AWS, you check their status page, maybe adjust some configs, or open a support ticket. When your home server is dropping packets, you're troubleshooting everything from the switch firmware to whether the cat knocked something loose. I bought a network cable tester. I learned about switch port negotiation. I started keeping spare drives.

But there's something satisfying about fixing a problem that's entirely yours. No waiting for support responses, no escalating through tiers of technicians who may or may not understand your setup. When I finally tracked down a memory issue that was causing random crashes, the relief felt earned in a way that cloud troubleshooting never did.

Where "Own Your Stack" Actually Delivered

The speed difference hit me first with the Git repositories. Cloning large repos locally versus pulling from GitHub felt like switching from dial-up to broadband. File operations that used to pause for a beat just happened instantly. My backup jobs ran faster. Docker builds that pulled from my local registry were noticeably quicker.

Control over data started feeling real when I wanted to analyze my personal metrics differently than what existing services offered. I could structure databases exactly how I wanted, keep logs as long as I wanted, export data in whatever format made sense. No API rate limits, no data retention policies I didn't set.

I fell down customization rabbit holes I hadn't expected. Custom dashboards that mixed system metrics with project stats. Automated workflows that would've required multiple cloud services and webhook integrations. A personal search engine that indexed everything I'd ever written, hosted locally. None of it was "necessary," but having the hardware sitting there made experimentation feel free.

The pride factor surprised me. When people asked about my setup, I found myself getting genuinely excited to show them the server rack I'd built in the basement. It felt like the difference between renting and owning, even though the analogy isn't quite right.

Where It Quietly Didn't Hold Up

Weekend maintenance became a real thing. Not every weekend, but often enough that I started factoring it into my schedule. Drive replacements, OS updates that required reboots, monitoring alerts about things that weren't quite broken but needed attention. The cloud promise of "someone else worries about the hardware" turned out to be worth something after all.

The internet dependency irony was constant. I'd moved everything local for control and reliability, but when my ISP went down, I was more screwed than when I'd been cloud-native. At least cloud services could fail over to other regions. My basement server rack had exactly one upstream connection.

Some services just work better with cloud scale. I tried self-hosting a CDN alternative and quickly remembered why content delivery networks exist. Email deliverability remained a problem I couldn't solve with better hardware. Real-time collaborative tools needed the global infrastructure I didn't have.

The backup strategy became its own project. Backing up to the cloud felt like cheating, but keeping everything local felt risky. I ended up with a hybrid approach: critical data replicated to a second server, with encrypted backups to cloud storage for disaster recovery. It worked, but it wasn't the clean "own everything" solution I'd started with.

The Middle Ground I Didn't Expect

Hybrid setups evolved organically. I kept development environments local but deployed production services to the cloud when reliability mattered more than ideology. Static assets served from my homelab with a cloud CDN in front. Databases replicated both locally and to managed services.

I missed fewer cloud services than I expected. Mostly the managed databases and the global CDN performance. But things like Lambda functions and managed Kubernetes clusters — services I'd thought were essential — turned out to be solutions to problems I didn't actually have when I controlled the full stack.

The monitoring paradox amused me: I ended up using cloud-based monitoring tools to watch my homelab. Uptime checks from external services, log aggregation that needed to work when my primary infrastructure didn't. The "own your stack" philosophy worked until I needed to know that the stack was broken.

"Good enough" became better than "perfect control" for more services than I wanted to admit. Running my own email server was theoretically possible but practically frustrating. Self-hosted video calls worked fine for personal use but couldn't match the reliability of Zoom for anything that mattered. Some battles weren't worth fighting.

The Reality Check

The real costs added up beyond the initial hardware purchase. Power consumption I hadn't calculated carefully. Two drive replacements. A proper UPS after the first one failed. Network equipment upgrades. Around $400 in additional expenses, which still came out ahead of what I'd been paying in cloud fees.

I learned skills I hadn't planned on: basic electrical work for the server closet, network troubleshooting that went deeper than checking cables, storage management that involved actual physical disks. My understanding of how computers actually work improved in ways that years of cloud development hadn't taught me.

Having bare metal to experiment on spawned projects I wouldn't have tried otherwise. A local LLM instance for coding assistance. Database experiments that would've been expensive to run in the cloud. Home automation integrations that needed local processing. The infrastructure became a platform for curiosity instead of just a hosting solution.

I'm sitting with the question of whether this was optimization or just expensive procrastination. The time I spent learning server hardware and network configuration was genuinely interesting to me, but it wasn't directly advancing my main projects. The reliability question remains open too — my uptime has been good but not great, definitely worse than the cloud services I replaced. As year two begins, I'm curious about the services I haven't tried moving yet, and whether I can build something better than the cloud alternatives for my specific needs, or if I'm just recreating wheels that already work fine.