A VMware TAM explaining his homelab hypervisor choices. Fair question.
If you’ve read anything else on this blog, you know I work with VMware by Broadcom professionally. So why does almost every post outside of work topics mention Proxmox? Shouldn’t I be running the stack I know best?
The short answer: I do run that stack. Just not everywhere. And the reasons why are less about philosophy and more about hardware, cost, and a Linux history that predates VMware’s existence.
Where I Come From
I didn’t start my career with a hypervisor. Hypervisors for x86 hardware barely existed yet. I started with a 14.4 modem and a stack of ambition that was probably unreasonable for a student at the time.
This was the late 1990s. I was at HTL — an Austrian technical secondary school — and I decided to start a project: every student should be able to build their own homepage and get an email address. That sounds trivial now. Back then, it wasn’t. Schools didn’t hand out email addresses. Personal websites meant GeoCities if you were lucky.
To make it work I needed a mail server and a web server. So I bought the O’Reilly sendmail book — the thick one — and spent days reading configuration options, testing, breaking things, reading more. Then Apache. Same process. No Stack Overflow, no tutorials written for beginners. You read the documentation, you understood the mechanics, or it didn’t work.
I landed on Red Hat and stayed there — through the early days, through CentOS, through the years when “enterprise Linux” meant something you compiled yourself and understood completely. I remember needing to rewrite a graphics driver in C to get X working on my GPU. Not patch it — rewrite the relevant parts. That’s not a complaint; that was the job. The upside of that era was that you ended up understanding your stack from the bootloader up.
Worth noting: while I was doing all of this, the hypervisor as we know it today didn’t exist yet. The VMware founders were still in a Stanford research lab working on what would become the Disco virtual machine monitor project. VMware was incorporated in 1998 — in stealth mode — and only went public in early 1999. The idea of running multiple isolated operating systems on commodity x86 hardware, cleanly, with reasonable performance, was still a research problem being solved down the road.
Which is why, when VMware GSX Server launched in 2001, I was on it almost immediately. That shift — from “bare metal or nothing” to “full hardware abstraction on a server” — was one of those moments where you could see the entire industry about to change. I moved into the VMware ecosystem professionally and haven’t looked back. I work with it every day and I see what it does for customers running serious infrastructure.
But “right tool for enterprise workloads” and “right tool for my homelab and rented servers” are different questions. And someone who spent days reading sendmail source to understand why a config option behaved unexpectedly doesn’t make hypervisor choices based on habit.
Three Environments, Three Answers
The Homelab
My homelab runs on physical hardware I own. Some of those machines are older — bought when they were mid-range, now solidly in the “aging but capable” category.
The problem with aging hardware and current hypervisors is a familiar one: newer versions drop support for older hardware generations. Running an unsupported configuration isn’t just philosophically uncomfortable — it means no security updates. For a homelab that touches my home network and runs services I actually use, that’s not acceptable.
Proxmox runs happily on this hardware. It’s based on Debian, gets regular security updates, and gives me KVM virtualisation and LXC containers without requiring a hardware refresh I haven’t prioritised. Simple as that.
The homelab also has two dedicated newer servers — machines I bought specifically for running VMware VCF stacks for testing and experimentation. That’s the TAM part of the setup: you can’t support customers running complex VMware environments if you don’t have a place to reproduce, test, and experiment yourself. Those servers run what they’re supposed to run. The older ones run Proxmox.
One more thing, and I mean this more seriously than it might sound: if you have server hardware or GPUs sitting in a corner collecting dust — hardware that would be useful in a proper lab — I would give it a significantly better home than your storage room. Current-generation server hardware, GPUs for AI/ML workloads, anything that belongs on a real HCL: it would be actively used, tested, and occasionally broken in interesting ways. The karma implications are straightforward. Get in touch — I’m easy to convince.
External Hosting Infrastructure
I rent dedicated root servers at Hetzner for everything public-facing — this blog, mail, Nextcloud, and a handful of other services. This is production infrastructure, not a homelab. It runs reliably and gets maintained seriously.
A word on Hetzner specifically: they run a hardware auction marketplace called Serverbörse where decommissioned servers get a second life at a fraction of the original cost. That’s where this infrastructure lives. Without the Serverbörse, the economics of self-hosting at this scale simply wouldn’t work for a personal project — and gex.guru probably wouldn’t exist. Hetzner does genuinely good work, and the Serverbörse is one of the better-kept secrets in the self-hosting community.
On rented bare-metal, ESX licensing doesn’t make economic sense. Hetzner doesn’t offer a managed VMware path for root servers, and bringing your own licensing to someone else’s hardware creates a layer of complexity that solves no real problem. Proxmox on a current Debian base is the right fit: open source, actively maintained, capable of running every workload I have, and free to use on hardware I’m already paying for. It’s not a compromise — it’s a considered choice.
On-Site Locations
At the locations where I run on-site infrastructure — home automation, cameras, network management, local services — Proxmox is again the common thread. The hardware is a mix of small form-factor machines and purpose-built nodes. ESX doesn’t enter the picture here for the same reasons: hardware support, cost, and the fact that these nodes run Linux-native workloads that fit the Proxmox/LXC model well.
What This Isn’t
This page isn’t a criticism of VMware products. I’m not making the case that Proxmox is better, or that enterprise teams should reconsider their hypervisor strategy, or anything of the sort. I work in the VMware ecosystem professionally and I’ll leave product comparisons to people who aren’t paid to support those products.
What I am saying is that infrastructure decisions are context-dependent. Homelab hardware constraints, rented server economics, and production reliability requirements are all different problems. Proxmox solves the ones I have outside work.
That’s why almost every non-work post on this blog mentions it.
One More Thing
I’ll be honest about something else while I’m at it: this blog wouldn’t exist in its current form without Claude. I’d been meaning to revive gex.guru for years — the ideas were there, the infrastructure was there, the drafts were not. Claude became the thinking partner that actually got things written: architecture discussions, post structure, debugging sessions documented in real time, and the occasional reality check when I was about to publish something that would have made a penetration tester very happy.
I mention this not as a disclaimer but as a data point. If you’re a technical person who has been putting off writing because the blank page is the hardest part — an AI assistant that can work through the architecture with you and then help you explain it clearly is a genuine force multiplier. The ideas and the infrastructure are still yours. The activation energy just gets lower.
If you’re hitting the same hardware wall in your homelab — older machines, newer hypervisor dropping support — the Proxmox VE documentation and the Proxmox Community Scripts project are the two resources I’d start with.