Rich Gibbs

Why I started a homelab: cost, control, and a portfolio I can show

homelab · documentation · self-hosting · soc-analyst · career

This is the first post in a series written from a homelab repository that is kept as a learning log and a security portfolio. The repo states three goals: cut cloud costs by migrating workloads off AWS onto owned hardware, own the infrastructure instead of renting it, and build hands-on security experience toward CompTIA Network+ (N10-009) and a SOC analyst role, including running a live honeypot. The documentation is split into hardware notes, per-service reference docs that describe current state rather than history, and session-by-session runbooks that record why a thing was done, not just what was done. This post covers the reasoning only; it contains no hardware tour, no configuration, and no honeypot findings.

Source context

Based on the repository snapshot selected for this series; not a live infrastructure inventory. It describes that historic snapshot only. It is not a description of any current network, host or service, and addresses or names shown in examples are documentation placeholders, not observed values.

I keep a repository for my homelab. It is a learning log and a security portfolio for a lab I built from scratch, and it is pointed at a SOC analyst role.

This is the first post in a series I am writing from that repo, one file at a time, in order. The first file is the README, so this post is about the reasoning. Not the build.

The three goals

The README lists three.

Cut cloud costs. The direction is migrating workloads off AWS onto hardware I own. I am not putting a number on that here. The README does not have one, and a real figure later is worth more than a guess now.

Own the infrastructure. Full control, top to bottom, instead of renting it. That is a motivation, not a finished state.

Build a security portfolio. Hands-on practice rather than reading about it, including study toward CompTIA Network+ (N10-009) and running a live honeypot exposed to real internet attackers. Study toward—the repo lists it as a target, not a credential.

How the repo is organised

Three areas.

Hardware notes for the physical machines, including purchase records. Per-service reference docs that describe current state rather than history. And session-by-session runbooks that are build logs.

The split is a working decision, not filing for its own sake. Reference docs and build logs go stale in different ways. A reference doc is wrong the moment the thing changes, so it gets rewritten.

Why it is written this way

The runbooks capture not just what was done, but why. That includes the mistakes and how they were diagnosed.

The test I use is whether someone else could follow the reasoning — a hiring manager, or a future me who has forgotten the whole afternoon. Commands alone do not pass that test. A clean write-up that quietly deletes the wrong turns is the least useful kind of document, because the wrong turns are where the actual learning is.

So the goal is real troubleshooting, real incident analysis, and real infrastructure decisions. Not a polished after-the-fact summary.

What this post is not

No hardware tour. No configuration. No honeypot numbers or findings. Those come from later files in the repo, one file per post, and they will say what they can support.

Based on the README snapshot used to start this series, the repo was actively worked, roughly session by session, with the newest material in the runbooks. That is the repo as it stood when I pinned it for this series. It does not establish what is running today.

Next post: the next file in the repo.

— Rich

Frequently asked questions

What is this series covering?

One file from my homelab repository per post, worked through in order. This first post comes from the README, so it covers goals and documentation approach only. Hardware notes, per-service docs, and the build runbooks each get their own posts later.

Does this post describe my infrastructure as it is today?

No. It is based on the README snapshot used to start this series, which describes the repo as it stood when I pinned it. It does not establish that the current setup still matches, and nothing here should be read as verified present-day state.

What does the README say about CompTIA Network+?

The README lists Network+ (N10-009) as a study goal, not a certification it claims. This post does not establish my current certification status.