Overriding Environment Variables at the Repository Level in Renovate

Renovate supports per-repository overrides of environment variables, allowing individual repos (or shared presets) to tailor behavior without changing global service configuration. This gives repo owners controlled flexibility to switch registries, tweak proxy behavior, test new mirrors, or scope tokens to specific projects.

Why this matters

• Control at the edge: repos choose their own GOPROXY, HTTP/HTTPS proxy, or registry endpoints.

• Safer experimentation: trial alternative mirrors or service endpoints without affecting other repos.

• Compliance by design: Centrally whitelist which environment variables are overridable and source values only from approved secret stores.

• Minimal ops overhead: no server restarts or global config edits for per-repo needs.

How it works

Renovate’s configuration supports safely flowing values from your runtime environment into repository-level config via the following chain:

1. Provision the secure value into the runtime environment

2. Expose it to Renovate’s config as a secret

3. Whitelist the env var(s) you allow to be set

4. Let repos (or shared presets) opt-in via env using templating

1) Provision a secure value

Use your orchestrator or host to inject a secret value into Renovate’s environment (examples below). Name the secret clearly, e.g., ALT_GOPROXY, ALT_HTTP_PROXY, NPM_REGISTRY_AUTH.

• Kubernetes (Helm values):

renovateWorker:
  extraEnvVars:
    - name: ALT_GOPROXY
      valueFrom:
        secretKeyRef:
          name: my-renovate-secrets
          key: altGoproxy

2) Expose it in Renovate global config

Map runtime environment vars into Renovate config as secrets, and whitelist env keys you permit repositories to set.

config.js:

module.exports = {
  // Make runtime env available to config templating
  secrets: {
    ALT_GOPROXY: process.env.ALT_GOPROXY,
    ALT_HTTP_PROXY: process.env.ALT_HTTP_PROXY,
  },
  // Only these env vars may be set by repo configs
  allowedEnv: ["GOPROXY", "HTTP_PROXY", "HTTPS_PROXY", "NO_PROXY"],
};

Notes:

• secrets values are resolved server-side and can be templated into repo config.

• allowedEnv is a safe-list; repo configs can only set these env vars.

3) Let repos override at the preset/repo level

In a shared preset or renovate.json within a repo, set the desired env var using the secret:

renovate.json:

{
  "extends": ["config:recommended"],
  "env": {
    "GOPROXY": "{{ secrets.ALT_GOPROXY }}"
  }
}

Another example:

{
  "env": {
    "HTTP_PROXY": "{{ secrets.ALT_HTTP_PROXY }}",
    "HTTPS_PROXY": "{{ secrets.ALT_HTTPS_PROXY }}"
  }
}

Result: only repos that opt in to this preset (or define env directly) will use the alternate values.

Common use cases

• Alternate module/registry endpoints: GOPROXY, GONOSUMDB, GOPRIVATE, MAVEN_OPTS, GRADLE_OPTS

• Network controls: HTTP_PROXY, HTTPS_PROXY, NO_PROXY

• Scoped tokens via env: use secrets + preset to direct to repo-specific mirrors without leaking credentials into config

Best practices

• Security

  • Never hardcode tokens in repo configs; pass via secrets.

  • Keep allowedEnv tight—only approve what you intend to be overridable.

  • Store secret material only in your secret store; configs should only reference {{ secrets.* }}.

• Observability

  • Renovate redacts secrets in logs, but keep values out of plain text where possible.

• Change management

  • Use shared presets to standardize how repos opt-in.

  • Version your presets for safe rollouts.

Troubleshooting

• The environment variable isn’t applied

  • Ensure the key is listed in allowedEnv.

  • Confirm the repo extends the preset or defines env directly.

  • Check that secrets.MY_KEY is defined (non-empty) in global config.

• Unexpected value or missing secret

  • In the Renovate container/pod, print env to verify ALT_* value exists.

  • Confirm secret value has no trailing whitespace/newlines (e.g., use echo -n when encoding to base64).