FR
OverviewHardwareDeploymentServicesData
← My Homelab

My Homelab - Deployment

For my first hypervisor (in 2022 or 2023), I went with ESXi. Despite VMware's acquisition by Broadcom and the tightening of licenses, I was enthusiastic about tackling a standard hypervisor, widely deployed in companies.

So I installed it on what was at the time my single node, and started installing my VMs, from an Ubuntu 20.04 ISO. I created one dedicated to my Docker services, another with GPU Passthrough to train ML models, another on Windows to play video games...

It was all very long. I had to configure all IPs manually, deal with dark ESXi bugs (and apply workarounds like this one), manage Nvidia driver installation in virtualized environments... It took me hours of digging through forums before understanding that I needed to install the kernel-open version of the drivers for it to work properly with GPU passthrough.

Once the environment was in place, I told myself, "Ah, I can FINALLY get to work on my projects". And it was true, I was able to move forward on DealTracker. And then time passes.

  • My conscience: "You're still on Ubuntu 20.04, is that still up to date and supported?"

  • Me: Well no.

  • My conscience: "And maybe you'd need to update the Nvidia driver?"

  • Me: No way! I already spent an eternity getting it to work the first time, between that and Cuda, it won't work out of the box, and besides I have other plans this afternoon"

  • My conscience: "And file sharing between VMs then, is it really efficient? Samba was clearly not a good idea, NFS seems more suitable."

  • Me: ...

Welcome to a software environment paralyzed by its own state. It gradually depreciates against the evolution of technology, and the foresight of its author who discovers new methods. This constitutes a time-consuming technical debt that slows down projects and reduces productivity. It was time for a big cleanup and move on.

The Switch to Proxmox

Proxmox, that little paradise that always ends up appearing on the path of homelabbers.

When I bought new hardware in early 2026, I looked at ESXi licenses more closely. The free version has a limited API and an 8 vCPU per VM limit? You're kidding me right? It's my hardware, my time and there's no way the longevity of my work should depend on the goodwill of an organization motivated to make me pay as much as possible.

And so it was off to Proxmox.

Incredible: it works. The interface? Intuitive. The proprietary CLI is gone, everything is built on Debian. If you need something, the community is rich and can help you. And of course, if there's something you don't like, you can modify the code yourself.

It's a joy to see such a rich and complete open-source ecosystem. And with this fresh start, it was time to set up a much more robust solution to address the software paralysis I had encountered on ESXi. Let's try to learn from past mistakes.

Infrastructure as Code, Ansible Deployment, and Compose Stacks

To limit the cost of setting up these VMs and managing their environment, the key lies in automation.

Specifically, three distinct automations:

1. VM creation, done with Terraform

I use the excellent bpg proxmox provider to automate VM creation, defining their hardware resources (including passthrough) and network configuration.

Now, if a VM needs an I440FX chipset instead of q35, it's no longer an obscure note written in a corner and then forgotten, it's a declared and commented value in the code.

2. VM provisioning, done with Ansible

Once VMs are provisioned with Terraform, they need to be configured, that's Ansible's role. There are many roles on Ansible Galaxy that allow automating component installation, and you absolutely need to take advantage of that.

"Hey look at your kernel-open Nvidia installation that gave you so much trouble? You run the nvidia.nvidia_driver role and BOOM everything is clean. On the other hand, you do need to code the role that adds the 450W undervolt yourself, the role developed by Nvidia wasn't necessarily designed for homelabbers who care about their hardware..."

All VM configuration goes through it. Docker installations, SSL certificates, DNS configuration, disk management...

3. Service deployment with Docker compose

Now that the VMs are installed with all dependencies, all that's left is to deploy the services. This is done naturally with Docker compose, you just need to configure volume mounts and network management.

And there you go! Once these elements are in place, the satisfaction is real. So you destroy the environment and watch Proxmox show you that all VMs have been deleted. Then you relaunch, and everything happens on its own. VM creation, driver installations, certificate management... and poof. It works. PiHole is available, GitLab too. You can watch a movie with Jellyfin.

The big victory is that this deployment is achieved through a declarative and replicable process that is versioned:

  • In case of error during state adjustment, it's possible to stabilize the environment by deploying an older version
  • An update is reduced to changing a value in the code.
  • Creating new VMs is adding a few lines of code