DevSecOps homelab pipeline

Most engineers learning DevSecOps assemble pieces on a managed cloud and never see what's underneath. This homelab inverts that — every layer is on the table, from the kernel up. The point isn't to replace cloud; it's to know what cloud is hiding.

The artifact is a reference architecture for secure software delivery: source, build, scan, deliver, run, observe — wired together end-to-end, on hardware I own.

Hardware

Bare-metal commodity boxes. No managed control plane, no cloud autoscaling. Kubelet, etcd, kube-proxy — all of it visible.

Idempotence

The cluster has to stand up clean from a single command and tear down without leaving state behind. If a step isn't reproducible, it doesn't ship.

Self-hosted

Every tool in the chain runs inside the cluster — no SaaS, no external CI. The point is to learn what each piece does, not to outsource it.

Security posture

Static analysis (SonarQube), policy gates in CI, signed artifacts — the same boxes a regulated pipeline checks, on a budget of zero.

Four tools, one cluster. Each one owns a different stage of the software lifecycle, and they pass artifacts between each other over Kubernetes-native primitives.

Source · CI

GitLab CE hosts repositories and runs pipelines. Runners scale as Kubernetes pods so concurrent jobs don't fight for one host.

Static analysis

SonarQube fronts the merge-request pipeline — quality gates block merges that introduce blocking bugs or security hotspots.

Delivery

ArgoCD watches a Git-tracked manifest repo and reconciles the cluster. Every production change is a commit; rollback is a revert.

Observability

Grafana with a Prometheus stack scrapes the cluster, the pipeline tools, and the workloads they ship — one dashboard for "is the platform alive."

• Whole stack stands up from a single make up against a clean host — manifests, secrets, ingress, observability.
• Tear-down is also one command. Nothing on the host outside Kubernetes survives the reset.
• The architecture became my teaching artifact for engineers rotating into DevSecOps roles — the diagram fits on one page.

Running CI inside the same cluster you're delivering to is pedagogically clean and operationally fragile — a misconfigured runner can stall the cluster it's supposed to deploy to. A next iteration would split CI to a sibling cluster, mirroring the boundary most production setups draw.