eblume/blumeops
1
1
Fork 0
Code Issues Pull requests Projects Releases 83 Packages Wiki Activity Actions
blumeops/docs/explanation/no-helm-policy.md
Erich Blume 3c819cf16e Fix Homepage migration date: 2025-12 → 2026-02 (per git history) 
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
2026-04-04 09:53:48 -07:00

2.3 KiB
Raw Blame History

title modified tags
No Helm Policy 2026-04-04
explanation
kubernetes

No Helm Policy

Note: This article was drafted by AI and reviewed by Erich. I plan to rewrite all explanatory content in my own words - these serve as placeholders to establish the documentation structure.

BlumeOps avoids Helm charts as a deployment mechanism. Plain kustomize manifests are the standard for all services.

Rationale

Helm templates add a layer of abstraction that works against the simplicity of Kubernetes YAML manifests. Go templates embedded in YAML are hard to read, hard to diff, and hard to reason about. A manifest should be a manifest — not a program that generates one.

Kustomize overlays preserve the readability of plain YAML while providing the composition and patching features needed for environment-specific configuration. Version bumps are a one-line newTag edit in kustomization.yaml, and kubectl diff shows exactly what will change.

Current State

All services in blumeops use kustomize manifests except:

  • 1Password Connect — still deployed via Helm chart (connect-helm-charts v2.3.0). Migration is a future goal.

Migration History

Services previously deployed via Helm that have been migrated to kustomize:

Service Migrated Notes
Grafana 2026-02 Converted during v12.x upgrade
CloudNative-PG 2026-02 Switched to upstream release manifest via forge mirror
External Secrets 2026-03 Static manifests rendered from chart
Homepage 2026-02 Replaced chart with plain manifests
Immich 2026-04 Converted during v2.6.3 upgrade

Guidelines

  • Do not introduce new Helm chart dependencies. When deploying a new service, write kustomize manifests directly — even if the upstream project provides a Helm chart. The chart's helm template output is a fine starting point for writing those manifests.
  • When upgrading a Helm-based service, consider whether it's a good time to migrate off Helm as part of the upgrade.
  • Upstream manifests can be referenced directly in kustomization.yaml resources (like ArgoCD and Tailscale operator do) or applied via ArgoCD's directory.include (like CloudNative-PG). Both avoid Helm.

Related