Helm Guide: Choose a Shape¶
What you'll learn here: how to pick the right Helm deployment shape for your environment, which questions matter first, and when a page in this section is a base install versus an overlay.
Start with these two questions¶
Before you look at any values file, answer these first:
- Do you want the adapter and upstream in the same pod, or managed separately?
- Are you choosing a full deployment shape, or just layering extra concerns like ingress or observability on top?
That split matters more than most of the individual settings.
Base shape or overlay?¶
In this Helm section, pages fall into two groups.
Base shapes¶
These are complete starting points. You can install them directly.
Overlays¶
These are additive values files. They are usually layered on top of a base shape with multiple -f flags.
If a page changes public hostname behavior, ingress behavior, or telemetry behavior without defining the full server and storage story, treat it as an overlay.
Quick decision matrix¶
| If your real need is... | Start here | Then layer this if needed |
|---|---|---|
| Fastest possible cluster trial | Standalone Quick Start | Nothing yet |
| One real service, still one pod | Standalone Durable Service | Browser-Facing Ingress or Observability-First Production |
| Adapter separate from upstream lifecycle | Distributed Shared Platform | Browser-Facing Ingress or Observability-First Production |
| Multi-replica adapter tier | HA Adapter Tier | Browser-Facing Ingress, Observability-First Production, or both |
| Humans will click upload or artifact links | Pick the right base shape first | Then add Browser-Facing Ingress |
| On-call ownership and heavy telemetry | Pick the right base shape first | Then add Observability-First Production |
A simpler rule of thumb¶
If you are unsure, use this sequence:
- start with Standalone Quick Start for a cluster trial
- move to Standalone Durable Service if one pod is still enough but the service is becoming real
- move to Distributed Shared Platform when upstream services should have their own lifecycle
- move to HA Adapter Tier when the adapter itself must stop being a single fragile pod
Then decide whether you also need:
Two mistakes to avoid¶
Treating overlays as complete installs
That usually leaves you with a values file that looks polished but still depends on chart defaults or missing server definitions.
Treating Redis as a file-sharing solution
Redis shares state, not files. If uploads or artifacts are involved, the adapter and the upstreams still need a shared filesystem path they can both reach.
Next steps¶
- Back to: Deploy with Helm - Helm overview and scenario index.
- Next: Example values files - checked-in copy-paste starters if you want real files instead of rebuilding YAML by hand.
- See also: Standalone Quick Start - the lightest base shape.
- See also: Layered values-file pairs - practical base-plus-overlay combinations once you have picked a base direction.