Goal
Make scaleplex discoverable to homelab users via ArtifactHub and kubesearch.dev.
Current state
- scaleplex is deployed as GHCR images (
scaleplex_worker, scaleplex_orchestrator, scaleplex_pms_dockermod) embedded in a bjw-s app-template HelmRelease — not its own chart, not its own HelmRelease.
charts/scaleplex/ exists but is an empty placeholder (.gitkeep).- The deploy repo (
Varashi/k8s, public) already carries the kubesearch GitHub topic.
Design tension (worth deciding before building)
Most homelab k8s users deploy via app-template, so a bespoke scaleplex chart may not be how people actually consume it. But the discovery platforms key off charts:
- kubesearch.dev crawls public repos with the
kubesearch topic and groups by the chart a HelmRelease references. Embedded-in-app-template => indexed as app-template, not scaleplex. To appear as its own scaleplex entry it must be deployed via a HelmRelease pointing at a named scaleplex chart in a public repo.
- ArtifactHub supports a Container images repository kind (list the GHCR images, no chart to maintain) and a Helm charts kind (nicer landing page + install story).
So the real decision: maintain a thin Helm chart (best landing page, only path that yields a scaleplex entry on kubesearch) vs app-template-first (document an example HelmRelease + register GHCR images as Container-images kind on ArtifactHub, lower maintenance, but no dedicated kubesearch entry).
Leaning toward: ship a minimal chart and keep a documented app-template example, so we get the ArtifactHub landing page + kubesearch entry without forcing the chart on app-template users.
Tasks
Notes
Defer until the solution is deemed ready. Visibility/launch channels (clusterplex-successor angle, selfh.st, r/selfhosted, home-operations Discord, awesome-* lists) tracked separately.
Goal
Make scaleplex discoverable to homelab users via ArtifactHub and kubesearch.dev.
Current state
scaleplex_worker,scaleplex_orchestrator,scaleplex_pms_dockermod) embedded in a bjw-sapp-templateHelmRelease — not its own chart, not its own HelmRelease.charts/scaleplex/exists but is an empty placeholder (.gitkeep).Varashi/k8s, public) already carries thekubesearchGitHub topic.Design tension (worth deciding before building)
Most homelab k8s users deploy via app-template, so a bespoke scaleplex chart may not be how people actually consume it. But the discovery platforms key off charts:
kubesearchtopic and groups by the chart a HelmRelease references. Embedded-in-app-template => indexed asapp-template, notscaleplex. To appear as its ownscaleplexentry it must be deployed via a HelmRelease pointing at a namedscaleplexchart in a public repo.So the real decision: maintain a thin Helm chart (best landing page, only path that yields a
scaleplexentry on kubesearch) vs app-template-first (document an example HelmRelease + register GHCR images as Container-images kind on ArtifactHub, lower maintenance, but no dedicated kubesearch entry).Leaning toward: ship a minimal chart and keep a documented app-template example, so we get the ArtifactHub landing page + kubesearch entry without forcing the chart on app-template users.
Tasks
charts/scaleplex/(orchestrator Deployment+Service, worker DaemonSet/Deployment + headless Service, pms_dockermod values/docs)helm push ... oci://ghcr.io/varashi/charts) or gh-pagesindex.yamlartifacthub-repo.yml(ownership claim) +artifacthub.io/*annotations in Chart.yaml (images, changelog, license, maintainers, links, screenshots)scaleplexHelmRelease example inVarashi/k8sso kubesearch indexes it as its own appNotes
Defer until the solution is deemed ready. Visibility/launch channels (clusterplex-successor angle, selfh.st, r/selfhosted, home-operations Discord, awesome-* lists) tracked separately.