homepage: Kubernetes service discovery via marker Ingresses #59

New issue

Open

opened 2026-10-04 13:11:03 +00:00 by lab · 0 comments

lab commented

2026-10-04 13:11:03 +00:00

Owner

Homepage discovers services by reading Ingress objects annotated with gethomepage.dev/*. This cluster routes through Caddy, so there are no Ingress objects and discovery has nothing to read.

Plan

Add inert networking.k8s.io/v1 Ingresses (no ingressClassName, so no controller claims them) annotated with:

gethomepage.dev/enabled: "true"
gethomepage.dev/name, gethomepage.dev/group, gethomepage.dev/icon
gethomepage.dev/href -- explicit, since no controller fills the rule

Homepage's RBAC already grants ingresses list/get.

Note

Lowest priority. Nothing changes without a git push either way, and homepage does not support multiple widgets per service via annotations, so widget-heavy services must stay in values.yaml. Keeping the grid in git is more IaC-correct than annotations nobody reads.

Homepage discovers services by reading Ingress objects annotated with `gethomepage.dev/*`. This cluster routes through Caddy, so there are no Ingress objects and discovery has nothing to read. ## Plan Add inert `networking.k8s.io/v1` Ingresses (no `ingressClassName`, so no controller claims them) annotated with: - `gethomepage.dev/enabled: "true"` - `gethomepage.dev/name`, `gethomepage.dev/group`, `gethomepage.dev/icon` - `gethomepage.dev/href` -- explicit, since no controller fills the rule Homepage's RBAC already grants `ingresses` list/get. ## Note Lowest priority. Nothing changes without a git push either way, and homepage does not support multiple widgets per service via annotations, so widget-heavy services must stay in `values.yaml`. Keeping the grid in git is more IaC-correct than annotations nobody reads.