Skip to content
CrumpNet
Go back

Why I Built CrumpNet

CrumpNet is my personal technology site for documenting the systems I build, the problems I run into, and the lessons I learn along the way.

At its core, CrumpNet is a homelab, but I do not want it to be just a pile of servers and services. I want it to be a place where I can practice infrastructure design, test tools, improve my documentation habits, and make better long-term technical decisions.

Why I Wanted a Homelab

I work with infrastructure professionally, and I wanted a place where I could safely test ideas outside of production environments.

The goals were simple:

A homelab gives me a place to slow down and understand how systems fit together.

Why Document It Publicly

Private notes are useful, but public writing forces a different level of clarity.

If I write something for myself, I can leave gaps. If I write something publicly, I have to explain:

That process makes me better.

What CrumpNet Covers

The lab is built around a few core areas:

Identity and infrastructure — Active Directory, Windows Server, DNS, DHCP, and the PKI that ties it together.

Visibility — Monitoring with Zabbix and security event collection with Wazuh. If something breaks or something looks wrong, I want to know about it.

Services and automation — Docker workloads, Linux administration, backup, and the scripting that keeps things running.

Network — VLANs and segmentation to keep the lab organized and isolated.

The goal is practical coverage: how I built it, what went wrong, and what I would change.

What I Will Not Publish

Some details do not belong on a public website.

I will avoid publishing:

The goal is to share the design and lessons, not expose the environment.

Where This Goes From Here

CrumpNet will grow as the lab grows, with a focus on practical notes, real lessons learned, and decisions that are worth remembering.

If it works the way I intend, CrumpNet becomes something I can reference during an outage, hand to a colleague, or revisit years from now without having to reverse-engineer my own thinking. Good documentation holds up over time. This is my attempt to write that way.


Share this post: