I Built a Home Lab Instead of Paying for Everything in the Cloud

I didn't really set out to build a home lab.

It started with wanting somewhere to run a few things. Then I needed Docker. Then a database. Then a reverse proxy. Then another service. Eventually there were VMs, containers, monitoring, networking, cloud backups, databases and enough random experiments that calling it a "server" didn't really describe it anymore.

At some point, I realized I had accidentally built my own little infrastructure environment.

It Started With a Server

The interesting thing about a home lab is that you don't need to start with some huge enterprise setup.

You start with whatever hardware you can get your hands on.

Over time, I ended up working with enterprise hardware as well, including Dell server hardware with multiple Xeon CPUs, a large amount of RAM and SSD storage.

At that point, there was enough compute available that running multiple workloads on one physical machine made much more sense than buying a separate machine for every project.

Then Proxmox Became the Foundation

Proxmox became the layer underneath everything.

Instead of installing applications directly onto the physical server, I could create virtual machines and Linux containers and give each workload its own environment.

Physical Server
        |
        v
    Proxmox VE
        |
        +---- VM
        |
        +---- VM
        |
        +---- LXC
        |
        +---- LXC
        |
        +---- LXC

This completely changed how I approached running software.

If I wanted to try something new, I didn't have to worry about polluting the main operating system. I could create a container or VM, experiment, break it, rebuild it and move on.

Then I Started Putting Real Services on It

This is where the home lab stopped being just a playground.

I started running things that I actually cared about.

Docker workloads, databases, backend applications, frontend applications, reverse proxies and infrastructure services all started finding a home somewhere in the lab.

Eventually there were services for things like:

• Application backends
• Frontend applications
• MongoDB
• PostgreSQL
• Docker workloads
• Reverse proxies
• Cloudflare Tunnel
• Monitoring and logging
• Development environments
• Random experiments

And because these weren't all isolated experiments anymore, suddenly uptime started to matter.

Docker Became a Big Part of It

Docker made it much easier to run applications without worrying too much about the underlying operating system.

I could define an application using Docker Compose, bring up the services, configure their networks and volumes, and recreate the environment when necessary.

That also meant I could keep my application infrastructure separate from Proxmox itself.

Proxmox
   |
   +---- VM
          |
          +---- Docker
                  |
                  +---- API
                  +---- Frontend
                  +---- Database
                  +---- Supporting Services

It wasn't always elegant, but it was incredibly useful.

Then Networking Became a Thing

This is probably where a home lab starts becoming a real home lab.

Once you have several VMs and containers, networking stops being something you can ignore.

I had to deal with static IP addresses, port forwarding, reverse proxies, VPNs, Docker networking and services running both inside and outside containers.

One of the simplest things I learned was also one of the most useful: know where a service actually lives.

For example, localhost inside a Docker container is not the same thing as the physical host. A service running on the host needs to be addressed differently from another container on the same Docker network.

These are small details until something stops working at 2 AM and you have to figure out why.

The Home Lab Started Talking to the Cloud

One of the things I found interesting was that I didn't have to choose between local infrastructure and cloud infrastructure.

I could use both.

                 Internet
                    |
             +------+------+
             |             |
          Cloud         Home Lab
             |             |
       Cloud VM        Proxmox
             |             |
          Database      Services

This eventually became useful for applications where I wanted the performance and control of local infrastructure while still having cloud resources available for redundancy or remote access.

Then the Database Became Important

Running a database in a home lab feels easy until the database becomes important.

I worked with MongoDB replica sets where one member was running locally and other members were hosted in the cloud.

The idea was simple: if the local infrastructure disappeared, there would still be database infrastructure somewhere else.

The reality was much more interesting.

At one point, a MongoDB instance crashed with a segmentation fault and refused to start normally. The server had also been offline for several days, which made the database state and replication situation something I had to investigate carefully.

This was one of those moments where the home lab stopped feeling like a hobby.

When the database is important, you can't just reboot everything and hope for the best.

Then I Learned About Indexes the Practical Way

Another problem appeared when an application became slow.

One particular patient search endpoint was taking far longer than it should.

Instead of immediately throwing more hardware at it, I looked at the database.

After adding the appropriate indexes to the collection, the search time dropped dramatically. A query that had been noticeably slow could execute in roughly 2 milliseconds.

That was a satisfying home lab moment because the solution wasn't buying more hardware.

It was understanding what the software was actually doing.

I've Also Moved Databases Around

At another point, I moved from a hosted PostgreSQL database to a local PostgreSQL setup running through Docker.

That came with its own set of problems.

One of them was a pg_dump version mismatch between the client tool and the PostgreSQL server.

It wasn't some catastrophic infrastructure failure, but it was another reminder that software versions matter even when the underlying database itself is perfectly healthy.

Things Break in Unexpected Ways

That's probably my favorite part of having a home lab.

You get to see problems that would normally be hidden behind a cloud provider.

When a hosted service has a networking problem, you might simply see an error page.

In a home lab, you might discover that the ISP connection keeps dropping, the reverse proxy can't reach the backend, the container can't reach the host, or the database is suddenly being accessed over a slower network path.

At one point, the internet connection at the server itself was unreliable and kept dropping. That affected services that depended on cloud infrastructure.

It was a good reminder that even a "local" server can have a surprisingly large dependency on the internet.

Then There Are the Upgrades

Upgrading applications is one thing.

Upgrading the platform underneath all of them is another.

I went through Proxmox upgrade issues involving package availability and repository configuration. When the system moved toward newer Debian and Proxmox repositories, I also ran into the enterprise repository requiring authentication.

None of this is particularly exciting until you remember that the hypervisor is underneath everything else.

If you break the hypervisor, you don't just break one application. You potentially break the entire lab.

The Lab Became a Learning Environment

This is probably the biggest reason I kept expanding it.

I could learn something and immediately try it.

Want to learn Docker? Run it.

Want to understand networking? Build a network and break it.

Want to understand MongoDB replication? Create multiple nodes.

Want to experiment with reverse proxies? Put one in front of your applications.

Want to understand what happens when a service disappears? Shut it down and see what breaks.

That feedback loop is something you don't get from simply reading documentation.

It's Also Become a Place for Random Projects

Not everything in the lab has to be useful.

Some projects exist because I wanted to know whether I could build them. Some exist because I wanted to learn a technology. Some exist because I had an idea and decided it was worth trying.

That's one of the advantages of having your own infrastructure. Experimentation becomes cheap.

I don't have to worry about paying for another cloud VM just to test something for a few days. I can spin something up locally, experiment with it and delete it when I'm done.

But a Home Lab Isn't Free

There is a tradeoff.

The hardware costs money. Electricity costs money. Storage eventually fails. Fans get noisy. Drives need replacing. Network connections fail. Backups need to exist somewhere.

And most importantly, the person maintaining the infrastructure is me.

A cloud provider handles a huge amount of operational work for you. Running things yourself means taking responsibility for those things.

So Why Not Just Use the Cloud?

For many workloads, the cloud makes perfect sense.

If I need a temporary server for a few hours, paying for a cloud instance is often easier than maintaining physical hardware.

But for experimentation, long-running services, development environments and workloads that I want complete control over, having my own infrastructure is incredibly useful.

I also don't want every technical experiment to come with a monthly bill.

What My Home Lab Is Now

At this point, I don't really think of it as a server anymore.

It's a collection of infrastructure that happens to live in my home.

                    Home Lab
                       |
                +------+------+
                |             |
             Compute        Network
                |             |
             Proxmox        Routing
                |
        +-------+-------+
        |       |       |
       VMs     LXCs   Storage
        |
      Docker
        |
   +----+----+
   |         |
 Apps     Databases
   |
Monitoring / Logging

Some parts are production workloads. Some are development environments. Some are experiments. Some probably shouldn't still be running.

That's the nature of a home lab.

Would I Recommend Building One?

If you're interested in infrastructure, absolutely.

You don't need an expensive server either. Start with an old PC, install Proxmox, create a VM and start running something.

You'll eventually break something.

That's actually the point.

Fixing a broken service teaches you more than a perfectly working tutorial ever will.

My Favorite Thing About the Lab

Looking back, the hardware isn't what made the home lab valuable.

It's the fact that I could keep asking "what happens if I do this?" and actually find out.

A database migration.

A broken network.

A failed container.

A Proxmox upgrade.

A new Docker stack.

A random service I wanted to test.

Every one of those became another small piece of experience.

That's ultimately what my home lab is for.

It's not about having a bunch of servers sitting in a room. It's about having somewhere to build things, break things and learn what actually happens underneath the software.

Current approach: Proxmox as the base virtualization platform, with a mix of VMs and LXCs, Docker-based applications, databases, networking services, monitoring and cloud-connected infrastructure.