@paigecalvert we can talk about what actually makes sense to include/update here, but I wanted to capture an issue now so I didn't forget about this. Came up during a slack thread with a customer

Pages to update:
https://docs.replicated.com/vendor/helm-install-overview
https://docs.replicated.com/vendor/helm-install-values-schema

What's wrong:
Both pages describe the injection as happening "during installation." The actual behavior is that the Replicated registry modifies values.yaml inside the chart tarball server-side when the chart is pulled — this happens identically for helm pull and helm install since both trigger an OCI pull from the registry. The current language leads customers (and our own team) to believe the injection is an install-time client-side concern, when it's actually a pull-time server-side transformation.

Proposed changes:

Replace "during installation" language with something like: "When an authenticated user pulls a Helm chart from the Replicated registry (via helm pull, helm install, or any OCI-compatible client), the registry injects customer-specific values into the global.replicated key of the chart's values.yaml before serving the chart."

Add a callout for GitOps/CI-CD workflows explaining that because the pulled chart tarball contains customer-specific secrets (dockerconfigjson, license data), customers who store pulled charts in git should either:

• Pull fresh at deploy time rather than committing the chart
• Strip global.replicated values before committing and reinject at deploy time from a secret manager

Clarify dockerconfigjson is a credential: The values schema page should explicitly note that global.replicated.dockerconfigjson contains registry authentication credentials (base64-encoded) and should be treated as a secret.

Add a note on SDK value consumption: Clarify that the Replicated SDK reads its configuration from Helm values only and does not currently support reading from Kubernetes Secrets or CSI-mounted volumes.