Schrondweiler Homelab:~$ ./
lang: en | fr
// DOCS
From git push to running service — the portal's own delivery pipeline
Portal — Public · Write-ups

← Write-ups

#

From git push to running service — the portal's own delivery pipeline

Context

The homelab's public portal didn't start as a full website — it started as proof that a change to code could travel, unassisted, from a commit to a running service on the cluster. Before investing in real content, I wanted the full delivery chain working end to end, on the simplest possible payload.

The problem

Two things mattered from the start, on top of "does it work":

What I built

A three-stage pipeline: build a container image on every push, publish it to a private registry, then apply it to the cluster. A dedicated namespace, a single replica to start. Once the skeleton proved itself, the project's folder structure (routes, services, configuration) sat ready and empty — deliberately — for what came next. That anticipation paid off: when I later split the portal into a public showcase and an authenticated admin area, that work filled the existing structure instead of reorganizing it.

Authentication came next, delegated to an identity provider using a standard protocol (OpenID Connect) rather than hand-rolled. At first it protected the entire site; later I inverted that, so only the admin area requires a login and the public pages are open by default — a public showcase and a gated control room, not one undifferentiated site behind a wall.

Pitfalls worth remembering

Where it stands

The pipeline is unremarkable by design — that's the point. Every later feature (login, a self-service catalog, a graphical console into a provisioned VM) rode on this same three-stage skeleton without needing to touch it again.

← Write-ups