Building my first homelab from the hypervisor up

I wanted somewhere I could break infrastructure without breaking a real product. A small homelab gave me that place.

The machine is a refurbished Dell OptiPlex 7070 Micro with an Intel i5-9500T, 16 GB of RAM, and a 512 GB NVMe SSD. It is not a server-room machine. It is quiet, power-efficient, and has enough headroom for the virtual machines and services I want to learn with.

The stack, one layer at a time

The current setup is deliberately simple:

Dell OptiPlex 7070 Micro
`-- Proxmox VE
    `-- Ubuntu Server VM
        `-- Docker
            `-- Self-hosted dashboard

Proxmox is the hypervisor on the physical machine. It hosts an Ubuntu Server virtual machine, and that VM runs containerised services through Docker.

Building each layer separately made the boundaries easier to understand. If a container cannot reach the network, I can work down through Docker, the guest operating system, the Proxmox bridge, and finally the physical connection instead of treating the whole setup as one black box.

Setting up Proxmox and the first VM

I installed Proxmox VE directly on the OptiPlex and connected its Ethernet interface through a Linux bridge. I also configured the appropriate Proxmox repositories and learned the basic management workflow through both the web interface and command line.

My first guest is Ubuntu Server. Once it was running, I set up SSH access from my Mac and stopped relying on the browser console for routine work. That small change made administration faster and gave me practice with remote access, host keys, permissions, and troubleshooting connectivity from both ends.

Getting a real service running

Inside the Ubuntu VM, I installed Docker and started with the official hello-world image. It is a tiny test, but it checks several things at once: the Docker daemon is running, the current user can talk to it, the host can pull an image, and a container can start successfully.

From there I deployed a self-hosted dashboard as the entry point for the lab. I have been editing its configuration, navigation, colour system, and responsive layout rather than accepting the default screen. It now gives me one place to reach the services I add later.

The troubleshooting was the useful part

Most of the learning happened between the successful screenshots. I worked through network connectivity, SSH access, Docker permissions, service restarts, configuration errors, and logs that only made sense after tracing which layer produced them.

The main lesson is that virtualisation and containers solve different isolation problems. Proxmox separates operating systems and machine resources. Docker packages applications inside a guest. Keeping that distinction clear makes backup, recovery, and fault-finding much less mysterious.

What comes next

The next additions will earn their place by teaching a specific operational skill:

• Forgejo or Gitea for self-hosted Git repositories
• WireGuard for controlled remote access
• Monitoring and centralised logs
• Automated backups with a tested restore path
• Databases and deployment environments for software projects
• A small Kubernetes environment once the single-host fundamentals are solid

The goal is not to collect services. It is to build a safe, repeatable environment where I can practise Linux administration, networking, deployment, security, and recovery with enough realism to learn from failure.