If you've been following along with this series, you know where things stand. The deployment and teardown of resources in my Devlab are automated now. VMs and containers can be created and destroyed through my CI/CD pipeline, the whole lifecycle handled in code. That's a solid place to be.
The obvious next move is to start deploying everything I want to run. More VMs, more containers, more services. But I want to stop here for a moment, because there's a decision baked into this build that I haven't fully explained yet, and it shapes everything that comes after it. I'm splitting this environment into two separate planes.
The Temptation to Just Start Deploying
When most of us build a lab, the first goal is to get something working. Stand up the server, install the app, configure the network, move on to the next thing. Security, monitoring, logging, and honest architectural thinking tend to get pushed to the end of the list, if they make the list at all.
For me, security, monitoring, and management have to be part of the conversation from the beginning. When I deploy a new VM or container, I don't want to circle back weeks later and figure out how I'm going to monitor it, secure it, ship its logs somewhere, or manage it. I want all of that to already be waiting for it.
That's the reasoning behind the split. One plane, the DevLab Plane, is where I build, develop, test, and automate. The other, the Management and Security Plane, is responsible for managing, monitoring, and securing the environment as a whole.
The DevLab Plane
This is where things get built and proven before they move anywhere else. Down the road I plan to add a second server that acts more like a production environment, so work can be tested here first and promoted there later. That's a problem for future me. Right now the DevLab Plane is the only place I'm deploying to.
And that's exactly why I paused. Now that I can automate deployment, I need to be careful about what I'm automating deployment into. It's one thing to spin up infrastructure on demand. It's another thing to spin it up into an environment that's actually prepared to manage and secure it.
That distinction matters more than it sounds like it does. When my pipeline finishes and reports success, that doesn't mean the VM is ready. It means the VM exists. Eventually I want "ready" to mean the VM has been deployed, secured, monitored, made observable, and pulled into the systems responsible for managing it. Getting there requires the second plane.
The Management and Security Plane
For that second plane I'm using a separate box, a small dedicated mini PC that sits apart from the lab server. It doesn't need to be anything exotic. What matters is that it's its own machine with its own job, and that job is managing, monitoring, and helping secure the rest of the environment.
I wanted the separation because the DevLab Plane is where I'm constantly experimenting, misconfiguring things, and tearing them back down. The systems that watch over the environment shouldn't be sitting in the middle of that. Here's what I want living on that plane.
Visibility, Detection, and Investigation
The first thing I care about is knowing what's happening in my environment, from both the network side and the endpoint side. How systems are talking to each other. What traffic is actually moving around. What users and processes are doing on individual hosts. Where the weak spots are.
More than that, if something does happen, I don't want my first reaction to be "what do I do now?" I want the answers already being collected before I need them.
For network visibility, detection, and threat hunting, I'm planning to test Security Onion. For endpoint visibility, what's happening inside the servers rather than just across the wire, I'm looking at Wazuh. Greenbone covers vulnerability management and scanning, so I can keep finding weaknesses before they turn into incidents. And Velociraptor gives me deeper endpoint investigation and forensics when I need to dig into a specific host.
The idea is that when something goes sideways, I can reconstruct the story. Where it started, what system was involved, what happened on that endpoint, what the network looked like at the time, whether it spread, and what else it touched.
I might swap some of these out later, and I'm fine with that. I'm not married to any particular product. I'm not building this lab so I can say I installed Wazuh or Security Onion or whatever tool is trending this month. I'm building an environment where I can see how these technologies fit together to solve real infrastructure problems. The tools can change. The requirement doesn't.
Identity, Trust, and Secrets
Next is controlling who and what is allowed to touch my infrastructure, and making sure sensitive material isn't scattered across a dozen servers or sitting in plain text inside config files.
For centralized authentication, SSO, and MFA I'm looking at Authentik. I also want to stand up an internal certificate authority, because as more services come online I need a real way to establish trust between them and issue certificates for internal communication instead of hand-managing certs on every box.
Then there are secrets. API tokens, passwords, encryption keys, service credentials, all of it needs somewhere safe to live. HashiCorp Vault is my current plan for that.
The goal is one place to manage identity, one way to establish trust, and far less sensitive information floating around the environment unmanaged.
Observability and Infrastructure Monitoring
Security visibility is only half of it. I also need to understand how the infrastructure itself is doing. If a server starts eating 95 percent of its memory, a disk quietly fills up, throughput drops off a cliff, or a service starts misbehaving, I want to hear about it from the environment, not from myself three days later when I try to use something and it doesn't work.
Prometheus handles metrics collection and storage. Grafana turns that into dashboards I'll actually look at. Loki gives operational logs a home and makes them searchable. Alertmanager handles telling me when something crosses a line.
Put together, that should let me spot bottlenecks, catch performance problems early, and correlate metrics against logs when I'm trying to understand what went wrong.
Software Supply Chain and Updates
This is the piece I've wanted to build for a long time, and honestly the one I'm most excited about. I want more control over where the software, packages, and container images in this environment come from. I'd rather not have every server reaching straight out to public repositories and pulling down whatever happens to be sitting there. I want a controlled internal path where things can be verified, scanned, and approved before they're made available to the rest of the infrastructure.
For container and OCI artifacts, Harbor gives me an internal registry with vulnerability scanning and image policies, so I have a say in what's allowed in. For Linux packages, something like aptly lets me mirror and manage APT packages internally, so my servers pull from a repository I control.
This doesn't magically solve supply chain attacks, and I'm not pretending it does. It gives me another control point, and it means I can answer basic questions about my own environment. Where did this come from? What version am I running? What are my systems even allowed to consume?
What I'm Actually Trying to Build
That's a lot of moving parts, and there will probably be more before this is done. But the mental model is straightforward. I want a centralized Management and Security Plane that gives me control and visibility over the infrastructure from the moment a resource is deployed through the rest of its life. Visibility across the network and endpoints.
A clear picture of system health and performance. A way to find vulnerabilities. Centralized identity and access. Protected secrets and established trust between internal systems. Control over where my software comes from.
And when something breaks or someone gets in, enough history and context to understand what happened, where it started, what was affected, and what I need to do about it. What I'm after is an environment where security, monitoring, observability, and management are part of the design instead of things I bolt on afterward.
So, Why Two Planes?
Because none of that belongs on the DevLab server. That machine is where I build, test, and break things on purpose. If the systems responsible for watching the environment live in the same place I'm constantly experimenting, they inherit all of that instability.
Keeping them separate means the DevLab Plane can change as much as it needs to while the management and security layer stays stable underneath it.
I wanted to talk through this before building it, because I don't think architecture and design come up nearly enough in home lab conversations. We get so focused on installing the next thing that we skip the question worth asking first: how should all of this actually work together?
That's the question I'm trying to answer. I'd rather build sound infrastructure before I start piling workloads on top of it. It's slower. There's no way around that, and I've made peace with it. The point of this lab was never to see how fast I can install another open-source application.
This is where I get to create controlled difficulty for myself. Break things. Fix them. Design something badly, understand exactly why it's bad, tear it apart, and do it again.
Build With Security in Mind
The next stretch of this series is going to focus on getting this plane up and running. Standing up the systems, testing the tools, figuring out how they integrate, and making sure the foundation is in place before I go back to deploying more resources on the DevLab side.
To be clear, the goal isn't an environment where an incident can never happen. That's not realistic. I don't care how locked down you think your setup is, nothing is impenetrable.
The goal is defense in depth. Multiple layers that make it hard to get in, hard to move around after getting in, more likely that I notice, and possible for me to reconstruct what happened if something does get through.
If you're building your own lab, you probably won't get all of this right the first time. I definitely won't. That's not a reason to skip it.
A few things I'd offer, since this is the part where I usually get questions:
- Don't deploy something just because someone on the internet said it was a good tool. Start with the problem you're trying to solve, then go find the thing that solves it.
- Don't learn these tools in silos. Installing a tool and memorizing where its buttons are is one skill. Understanding how it fits alongside network detection, vulnerability management, identity, observability, and incident response is a completely different one, and it's the one that matters.
If you want to understand how these technologies get used in production, build a lab where they're forced to work together. Leave the shiny object chasing behind. Build the environment, understand the architecture, understand why each piece is there, and then learn how they work together.
That's what I'm doing here. It's going to take longer, and it's probably not the most exciting way to build a home lab, but I'm confident I'll walk away from it having learned a lot more. That's it for this one. As always, stay geeking, stay curious. I'll catch you in the next one.
