HostKid — Why this project exists

Alright. Pull up a chair.

I'm a DevSecOps person. That's the label on the résumé. But I've also spent real time inside an IT team as a SysOps engineer — and honestly? The operational side always fascinated me. Not the slide decks. Not the buzzwords. The messy, hands-on reality of keeping infrastructure alive.

And that's where this story starts.

---

The problem I kept watching

Inside IT, I kept seeing the same pattern.

People working in a purely imperative mode on the hypervisor:

• Click here
• Clone there
• Edit netplan by hand
• Hope the IP is free
• Forget who created what last Tuesday

No tracing. No history of actions. No clean audit trail of what happened on Proxmox. Just humans clicking through a UI… and burning time.

Configuration drift. Orphaned VMs. Blind actions. The kind of operational debt you feel in your bones when something breaks at 2 a.m. and nobody remembers why that VM exists.

I hated that.

---

The pivot: stop clicking, start declaring

So with my team, we flipped the approach.

Why are we treating VM creation like a craft workshop… when we could treat it like infrastructure?

Enter Terraform + cloud-init on Proxmox.

Declare the specs. Clone from a template. Inject network, users, and bootstrap config automatically. Track every apply and destroy in version control. Make the hypervisor stop being a black box of unlogged clicks.

That experiment became a real utility: ProxGen — a Terraform project that provisions Proxmox VMs on demand from cloud images and templates.

No more manual netplan edits for IP and gateway. No more “wait, which node has the template?” chaos without checks. GitOps-shaped habits: plan, apply, destroy — with state that remembers what you own.

That success mattered. Not because Terraform is magic — because operations finally had a memory.

---

Then the idea grew

ProxGen was a provisioning engine. A utility.

And then my brain did what it always does after a win…

Wait. This is exactly how a company selling hosting — VPS, shared hosting, services — has to think. OVH. HostPapa. The whole industry.

If you can provision cleanly, you can productize.

If you can productize, you can sell.

If you can sell, you need DNS, email, billing, identity, monitoring, support, migrations, security…

Suddenly it wasn't “a Terraform script for IT.”
It was: what if I solidify all of my IT and operations knowledge by building a mini hosting company?

Not a toy blog post. A living system. A handbook. A testimony of good decisions and bad ones — because that's how we actually learn.

That project is HostKid.

---

What HostKid is

HostKid is my commitment to build, document, and operate a small hosting provider — not on a raw hypervisor alone, but on Apache CloudStack with KVM as the IaaS foundation.

ProxGen on Proxmox taught me automation discipline. CloudStack is where that discipline meets multi-tenant product semantics: accounts, offerings, networks, APIs — the machinery a hosting company actually sells.

We grow it volume by volume. Fundamentals first. Platform selection next. CloudStack operations after that. Products, then the flagship: the provisioning engine that turns a customer click into a running service.

By the end of the handbook, you shouldn't just “know CloudStack.” You should understand how a hosting company chooses its stack, how the business model maps to infrastructure, and how the technical layers make that business possible.

---

Choosing the platform (the short version)

Before we built volume folders and labs, I ran a proper evaluation: Proxmox, VMware / vSphere, and KVM via Apache CloudStack.

Proxmox stays in my story — ProxGen proved Terraform + cloud-init there. VMware stayed in the evaluation because enterprise hosts run on it and you need to speak that language. CloudStack won because HostKid needs an IaaS control plane built for service providers, not a hypervisor UI we duct-tape a product onto.

The full criteria, scoring, and tradeoffs live in The Engineering Handbook Volumes under How we chose the platform. Read that before you assume this was a random pick.

---

How the handbook is organized

If we're building a hosting company — not just a homelab — this can't be a pile of random notes. Each volume builds the next, so that by the later volumes you've effectively designed a small hosting provider from the ground up.

Phase	Volumes	What you get
Foundation	0 → 7	Business context, internet, Linux, platform selection, CloudStack, networking, storage, IaC
Platform	8 → 13	Kubernetes (internal), identity, portal, corporate ERP, DNS, email
Products	14 → 18	Shared hosting, VPS, object storage, monitoring, logging
Engine & ops	19 → 24	Provisioning engine (flagship), APIs, automation, security, support, migrations
Mastery	25 → 28	Solutions engineering, case studies, production ops, future evolution

---

The volumes at a glance

Twenty-nine volumes is a lot to dump on one intro page — and honestly, each one deserves more than a bullet. So here's the deal: the phase table above is the map. For the full walkthrough — including how we chose CloudStack over Proxmox and VMware — what every volume tackles, why it exists, what labs you'll run, and where Volume 19 becomes the flagship — jump into The Engineering Handbook Volumes. When you need skills, tradeoffs, or decision-making fuel from people who've already run this pain, grab Books That Help You Decide — the reading shelf right next to it in the sidebar.

---

Repository shape (target)

As the lab code grows, this is the shape we're aiming for:

In this knowledge base, the same journey lives under Knowledge base → Projects → HostKid, with one folder per volume.

---

How to follow along

1. Start here (you already did). Feel the motivation.
2. Read The Engineering Handbook Volumes when you want the full volume-by-volume story.
3. Browse Books That Help You Decide when you want external depth on skills and tradeoffs.
4. Open Volume 0 for the company / business lens.
5. Climb volumes in order — each one assumes the previous ones exist in your head.
6. When you reach Volume 19, connect the dots: customer request → running service.
7. Treat every bad decision you see documented as intentional teaching material.

Alright. Volume 0 is next. Let's go.