Designing an ESXi-Based Homelab as a Portfolio Platform for Hybrid Infrastructure, Modernization, and DR

Homelabs are often treated as personal playgrounds. A place to try new tools, break things, rebuild them, and learn along the way. There is nothing wrong with that, and I have used mine that way as well.

But lately, I have been looking at my lab differently.

Instead of seeing it only as a technical sandbox, I want to use it as a portfolio platform. Something that helps me document how I think about infrastructure, how I approach change, and how I can turn hands-on work into something more structured and visible.

That is the context behind this ESXi-based lab.

I already have a working environment running in it, including some Lab workloads and a K3S cluster, so this is not a greenfield setup. It is also not a lab I want to wipe and rebuild from scratch just to make it look cleaner on paper. In real life, infrastructure rarely starts from zero. It grows over time, usually under constraints, and I think there is real value in documenting that process honestly.

For me, that is what this lab is really about.

It is not just a place to run virtual machines or test Kubernetes. It is becoming a way to build visible proof-of-work around infrastructure architecture, modernization, resilience, and eventually more repeatable infrastructure-as-code-driven ways of working.

Why I’m building this lab

The main reason I am building this lab is not just to learn in private.

Learning matters, of course, but by itself it is not enough. If I want to move toward broader infrastructure architecture, modernization, and hybrid/cloud-relevant work, I need more than experience in my head. I need visible proof that shows how I think, how I structure an environment, and how I approach infrastructure change over time.

That is where the lab becomes more useful.
It gives me a place to test ideas and document them. To capture design intent, trade-offs, current limitations, and future direction. In other words, not just to build things, but to build a body of work that is easier to show, explain, and improve.

Why ESXi is the starting point

Starting with ESXi is the most practical and honest choice for me.

It reflects both the experience I already have and the infrastructure I currently have available in the lab. That makes it a much stronger starting point than pretending I am beginning from a cloud-native greenfield environment.

I do want the lab to move in a broader direction over time. I want it to support better documentation, more repeatable provisioning, stronger DR-oriented scenarios, and eventually some hybrid/cloud-aligned extensions. But I think it makes more sense to start from a foundation that is real, stable, and already useful rather than forcing complexity too early.

Current environment and constraints

At the moment, the lab is built around a single ESXi host. It has two CPU sockets with 20 cores each, 240 GB of RAM, and 2 x 250 GB SSDs. For a personal lab, it gives me enough room to run meaningful workloads and experiment without immediately hitting major resource limits.

The environment is already in active use. Right now, it includes some lab workload VMs and a K3S Kubernetes cluster with three control-plane nodes and three worker nodes. So this is not a blank environment that I am planning from scratch. It is a working foundation that already supports useful services.

The network side is still relatively simple. I do not currently have VLAN separation or a dedicated split between management and workload networks. That is one of the areas that can improve over time, but I am not trying to pretend the lab is already in its final form.

That current state matters because it shapes how I want to improve the environment.

I am not interested in tearing everything down just to rebuild the lab from scratch in a way that looks cleaner on paper. The existing workloads are useful, and I would rather improve the environment incrementally than destroy working systems for the sake of presentation. In practice, that feels much closer to how real infrastructure changes anyway.

I have already started documenting part of that journey through the Kubernetes side of the lab, but this post is more about the foundation underneath it and the direction I want the whole environment to take.

What this lab is meant to prove

The main purpose of this lab is not to show that I can run more services at home. It is to show that I can take an existing infrastructure base and improve it in a more deliberate way.

That means a few things.

First, I want to demonstrate architectural intent. Not just what is running, but why the environment is structured the way it is, what constraints exist today, and how I want it to improve over time.

Second, I want it to demonstrate documentation discipline. In my view, infrastructure becomes much more valuable when it is explainable. Architecture notes, diagrams, runbooks, and decision-making are all part of the work, not just something you add at the end.

Third, I want it to demonstrate a practical modernization path. The lab starts from a familiar virtualization base, but the direction is broader: more reproducibility, more structure, stronger DR-oriented thinking, and eventually a more hybrid-ready path.

And finally, I want it to demonstrate that learning is more useful when it turns into visible proof-of-work. Private learning matters, but if it stays private, it is much harder to use it as evidence of growth and direction.

Why documentation matters as much as implementation

One thing I want to avoid with this lab is treating documentation as an afterthought.

It is easy to focus only on what gets deployed: the virtual machines, the cluster, the services, the configuration. But if the goal is to build something that is professionally useful, then implementation alone is not enough.

What makes an environment more valuable is being able to explain it clearly. Why it exists, why a design choice was made, what the trade-offs are, what is still missing, and how it should change next.

That is part of the reason I am trying to build the lab with a stronger structure around it. Git for versioned documentation and future automation, Obsidian for planning and architecture notes, and the blog for public proof-of-work. The technical side matters, but so does the ability to communicate what the environment is trying to become.

Why I’m not rebuilding everything from scratch

One thing I do not want to do is destroy the current environment just to make the lab look cleaner for documentation purposes.

At the moment, the host is already running useful workloads, including a K3S cluster. Rebuilding everything from zero might look neater in a diagram, but it would not necessarily make the lab more useful.

In practice, infrastructure work is often about improving existing environments, not replacing them with perfect clean-slate designs. Working under constraints, preserving what already works, and still moving the environment in a better direction is part of the job. I think that makes this approach more realistic and, honestly, more valuable.

Why IaC is the next major focus

If I look at where this lab should go next, the biggest step is not adding more services.

It is making the environment more structured, more reproducible, and easier to improve over time.

That is why infrastructure-as-code is the next major focus for me.

Right now, the ESXi-based lab provides me with a solid technical foundation. The next step is to improve how that base is documented, versioned, and eventually partially provisioned or managed in a more repeatable way. That shift matters because it moves the lab from being mostly operational to being more aligned with modernization and architecture thinking.

How the lab will evolve from here

From here, the goal is not to turn the lab into a collection of random technologies. The goal is to make it more intentional.

The most important next step is infrastructure as code. The ESXi host already gives me a useful base, but I want to push the environment toward more reproducible and versioned ways of working. That is the shift that starts turning a lab from something operational into something closer to a real architecture portfolio.

After that, I want to strengthen a few specific areas: documentation quality, architecture artifacts, DR-oriented scenarios, and selective hybrid/cloud-relevant extensions where they actually add value. I am much more interested in an environment that grows with a clear purpose than one that expands by accumulating tools.

That is probably the main theme of the lab overall: not more complexity for its own sake, but better structure, better reasoning, and better proof of how the environment can change over time.

Closing

For me, the value of this homelab is not in its size or how many components I can fit into it. The value lies in using it intentionally: as a place to document decisions, improve structure, test ideas, and build visible proof of work over time.

This is only the current foundation, not the finished state. But that is exactly why it is worth documenting now.