Building a Practical Proxmox Homelab from Old Laptops

Why I started building a homelab?

I started building my Proxmox homelab because I wanted a place where I could safely break things, test infrastructure ideas, and understand how backend applications behave outside my local IDE.

Running an application on my main computer is easy. Running it as a service, on a VM, behind a network boundary, with persistent storage, limited resources, remote access, and recovery options is a different skill. That is the part I wanted to practice.

My homelab is not built from expensive server hardware. It is mostly based on old laptops and reused machines. Some of them are weak, with limited RAM and older CPUs, but that actually made the setup more useful. When hardware is limited, every service forces a decision: should it run in a VM, in Docker, directly on Debian, or not at all?

The basic setup

The main layer is Proxmox. I use it to create and manage virtual machines for Linux services, experiments, and lightweight Windows environments. Some machines are used as Debian-based service hosts. Others are used for remote automation tests, RDP experiments, and isolated development environments.

The setup is intentionally practical instead of perfect. I care more about learning real operational problems than pretending that my home setup is a production data center.

The homelab helped me test:

• PostgreSQL, Redis, and object-storage style services
• lightweight Windows VMs for automation experiments
• Tailscale remote access
• Wake-on-LAN relay ideas
• resource limits on weak hardware
• remote access through RDP and SSH
• networking problems between routers, switches, and subnets
• The “secret project” use case
• Docker-based service hosting

One of the reasons I built the homelab was to support a private project, which I will refer to only as the secret project.

The exact project is private, but the infrastructure problems around it are normal backend problems. It needs services that resemble a real application environment: a database, object storage, caching, background processing, remote access, and isolated testing areas. Some features are intentionally unrelated here, because the project itself is not the point of this post.

The point is that a homelab gives me a controlled place to test supporting infrastructure before touching more serious environments.

For example, I can test whether a service survives restarts, whether Docker volumes keep data correctly, whether a VM has enough memory, whether a database should run on the same host or separately, and whether remote access works when I am not in the same network.

Why old laptops are useful?

Old laptops are not ideal servers, but they are useful learning machines.

They usually have built-in batteries, low power usage, and enough performance for small services. They are also imperfect, which is good for learning. Some have weak CPUs. Some have limited RAM. Some are awkward with storage. Some are bad candidates for many VMs but still useful as monitoring nodes, VPN relays, small Docker hosts, or Wake-on-LAN helpers.

This forced me to think about resource usage more carefully. A full desktop environment on a weak VM is wasteful. A minimal Debian VM with Docker is usually much more reasonable. PostgreSQL, Redis, and object storage can run well if they are sized correctly and not treated like unlimited cloud services.

The biggest lesson here was simple: infrastructure design depends on constraints. Weak hardware teaches that faster than cloud credits.

Remote access and Tailscale

Remote access became one of the most important parts of the homelab.

I use Tailscale because it makes private networking much easier. Instead of exposing everything directly to the public internet, I can access machines through a private mesh network. This is useful for SSH, web dashboards, RDP, and administrative access.

The remote setup also made me think about reliability. If a machine is asleep or powered off, remote access alone is not enough. That led me into Wake-on-LAN experiments.

Wake-on-LAN sounds simple: send a magic packet and wake the computer. In practice, it depends on Ethernet, BIOS settings, operating system power settings, router behavior, MAC addresses, and whether a relay device exists inside the right local network. That made it a good networking lesson.

I explored the idea of a relay host that stays online and sends Wake-on-LAN packets locally. I also considered lightweight devices, including ESP32-style options, as potential helpers in the same LAN.

Virtual machines, containers, and trade-offs

A homelab quickly teaches that not everything should be a VM.

VMs are great for isolation. They are useful when I want a clean operating system, a separate environment, or a machine that behaves like a real server. But VMs also consume memory and storage. On old laptops, that matters.

Docker is better when I want several small services on one Linux host. For example, a Debian VM can run multiple containers with resource limits, persistent volumes, and simple restart policies. That is usually a better fit for PostgreSQL, Redis, admin tools, and small internal services.

The decision is not “VMs vs Docker”. The real question is: what isolation do I need, and how much overhead can the machine handle?

What this taught me

This homelab changed how I think about backend development.

Before working with infrastructure directly, it is easy to focus only on code. But deployed software depends on many things that are not inside the application source code: DNS, storage, memory, ports, reverse proxies, operating system services, firewall rules, backups, remote access, and recovery paths.

The homelab gave me a place to practice those problems without fear. If I break a VM, I can rebuild it. If a Docker volume is misconfigured, I can inspect it. If a service uses too much memory, I can reduce it. If Wake-on-LAN does not work, I can debug the network path.

That feedback loop is valuable.

Final thoughts

My Proxmox homelab is not finished, and that is fine. A homelab is not a single project with a final version. It is a learning environment.

For me, it became a practical bridge between software development and infrastructure. It helped me understand how applications live after they are built: how they run, fail, restart, communicate, persist data, and stay reachable.

That kind of experience is hard to get from tutorials alone. You need a system you control, real constraints, and enough freedom to break things.

That is exactly what this homelab gives me.