tiny

The Shared Operator Chart

Modules do not ship their own Helm charts. Every module — first-party or yours — deploys with the same shared chart, tinysystems/tinysystems-operator, published at https://tiny-systems.github.io/module/. A module release is an image plus a values overlay for that chart; there is no per-module Chart.yaml.

How It Works

The operator chart deploys any module image as a controller-manager Deployment. Which module it runs is entirely a matter of values:

helm repo add tinysystems https://tiny-systems.github.io/module/

helm install my-module tinysystems/tinysystems-operator \
  --namespace tinysystems \
  --set controllerManager.manager.image.repository=ghcr.io/my-org/my-module \
  --set controllerManager.manager.image.tag=1.0.0

The chart wires the container to run with --grpc-server-bind-address=:8483, health/metrics addresses, and the OTEL collector DSN. It also runs the module binary's own pre-install hook (namespace validation: reserved namespaces are refused, and the namespace must carry the tinysystems.io/managed=true label) and pre-delete hook on uninstall.

In practice you rarely run helm by hand: tiny install <module> resolves the module from the configured repo indexes and installs this chart with the right image and overlay. Each module's module.yaml in the index pins the chart and chartVersion it installs with:

versions:
  - version: 0.8.13
    image: ghcr.io/tiny-systems/kubernetes-module:0.8.13
    chart: tinysystems/tinysystems-operator
    chartVersion: 0.2.10

Values You Actually Set

Image

controllerManager:
  manager:
    image:
      repository: ghcr.io/my-org/my-module
      tag: "1.0.0"

RBAC

The chart creates the module's ServiceAccount and ClusterRole. Two knobs:

rbac:
  # Access to core resources (pods, services, deployments, ingresses).
  # Required for modules that use ExposePort (e.g. http-module).
  enableKubernetesResourceAccess: false
  # Extra rules for modules that need more
  extraRules: []

Do not write this block by hand. Generate it from the module image so the grant always matches what the code declares via registry.SetRequirements:

docker run --rm --entrypoint /manager ghcr.io/my-org/my-module:1.0.0 \
  tools rbac-values > values.yaml

That output is exactly the overlay committed next to the module's module.yaml in a module repo. Drift between hand-written overlays and the compiled-in declaration is how components end up silently 403ing at runtime.

Secrets

secrets:
  enabled: false   # grant get/list/watch on Secrets namespace-wide

Enable for modules whose components resolve [[secret:<name>/<key>]] placeholders in node settings.

Storage

storage:
  enabled: false
  size: 1Gi
  storageClassName: ""
  mountPath: /data

Bundles

The chart carries curated third-party subcharts (e.g. tei, pgvector) that module authors can request via the SDK's module.Bundle. They are enabled per install:

tiny install embedding-module --bundle tei
# or: --set tei.enabled=true on the helm command

One Helm release owns the module and its bundles, so helm uninstall cleans up both.

Upgrades and Uninstall

# New module version = same chart, new image tag
helm upgrade my-module tinysystems/tinysystems-operator \
  --reuse-values \
  --set controllerManager.manager.image.tag=1.1.0

helm uninstall my-module

What You Do NOT Do

  • No Chart.yaml, templates/, or helm package in your module repo.
  • No chart publishing — the shared chart is maintained in the SDK repo (tiny-systems/module, under charts/) and released to the GitHub Pages Helm repo.
  • No hand-written RBAC manifests — declare requirements in code, generate the overlay.

Next Steps