docs+ui: explain why podinfo/hello share a Caddy target; genericize hero copy
All checks were successful
build-hello-app / build-and-push (push) Successful in 32s

docs/03-flux.md: clarify that podinfo/hello-app pointing at the same
<VM_IP> in Caddy isn't a routing choice - there's only one VM right now,
doubling as both control plane and workload node, and Traefik is what
actually does per-hostname routing once the request lands there.

index.html: drop the specific "Dell T630" hardware reference from the
public-facing tagline in favor of a generic "Home server".

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Y4YNpuC2bgT224suQLLJ7B
This commit is contained in:
CodeGit 2026-09-04 10:48:17 +01:00
parent a803eda2c0
commit b3da26e337
2 changed files with 11 additions and 2 deletions

View file

@ -102,7 +102,7 @@
<body>
<main>
<h1>Homelab GitOps Platform</h1>
<p class="tagline">Terraform-provisioned k3s cluster on a Dell T630, deployed and kept in sync entirely through GitOps. This page is served from it — and this line proves it: edited via git push.</p>
<p class="tagline">Terraform-provisioned self-hosted k3s cluster on a Home server, deployed and kept in sync entirely through GitOps. This page is served from it — and this line proves it: edited via git push.</p>
<div class="badge-row">
<span class="badge">commit <strong>__GIT_SHA__</strong></span>

View file

@ -452,7 +452,16 @@ podinfo.boglabob.com CNAME boglabob.com
hello.boglabob.com CNAME boglabob.com
```
Then in Caddy's own config, using the VM's pinned IP from stage 2:
Then in Caddy's own config, using the VM's pinned IP from stage 2. Both
blocks point at the exact same `<VM_IP>` — that's not a mistake, there's
only one VM right now, and it's simultaneously the control plane *and*
the only place pods can run ("Why one node is enough," above). Caddy
isn't picking between podinfo/hello-app here at all — it just forwards
everything for both hostnames to that one node's port 80, and it's
Traefik, once the request lands there, that actually reads the `Host:`
header and routes to the right backend. This changes in stage 4, where
there are real node IPs to load-balance across (`docs/Caddyfile.example`'s
multi-node blocks):
```
podinfo.boglabob.com {