No Helm chart — environment customization requires manual manifest forking

[avelino]

Problem

Once Kubernetes manifests exist (#68), teams with more than a trivial deployment will need to customize values across environments (dev, staging, prod): replica counts, resource limits, image tags, ingress hostnames, auth secrets, and backend configurations.

Without a Helm chart (or equivalent templating), every environment fork maintains its own copy of the manifests, and keeping them in sync becomes a manual process.

What varies across environments

Parameter	Dev	Prod
Replicas	1	3+
Image tag	latest / branch SHA	semver release
--insecure flag	yes (no TLS)	no (TLS at ingress)
servers.json content	test backends	production backends with real tokens
Resource limits	minimal	tuned to observed usage
Ingress / hostname	none or localhost	mcp.example.com
Audit log storage	ephemeral	PersistentVolume
Auth provider config	disabled or test tokens	JWT/OIDC (#57)
ACL policies	permissive	strict per-role

Why this matters

The MCP proxy is designed to be a shared infrastructure component — multiple AI clients (IDE extensions, CLI tools, agents) connect to a single proxy that manages backend pools. This "deploy once, connect many" pattern means the proxy deployment is high-leverage: getting it right matters, and getting it wrong affects every connected client.

Helm (or Kustomize overlays) is the standard way the Kubernetes ecosystem handles this. Without it, adopters either:

1. Write their own Helm chart (duplicated effort across every team)
2. Use raw manifests with sed/envsubst (fragile, error-prone)
3. Skip Kubernetes entirely and use docker-compose only (limits production viability)

Dependencies

• No Kubernetes manifests — proxy requires undocumented operational knowledge to deploy #68 — base Kubernetes manifests must exist first
• Container deployment requires file mounts — no inline config or writable-path overrides #67 — container config model needs to be settled before templating it
• Dockerfile requires pre-built binary — no reproducible build from source #65 — container image must be buildable from source

Expected behavior

A Helm chart (or equivalent) in the repository that allows deploying the proxy with a single helm install / helm upgrade, with sensible defaults and clear documentation of available values.