Use a single public GitHub App for multi-org Renovate CE

Date: 2026-06-14 Status: Accepted Decision: hl-543e Deciders: Sean Brandt

Context

Renovate CE is configured with exactly one GitHub App, and the cluster needs CE to serve multiple GitHub organizations. GitHub Apps are either private (installable only by the owning account) or public (installable by any account). CE’s architecture ties one server instance to one App identity.

Decision

Create one public GitHub App (installable by any account) and install it per-org. A single CE instance serves all installations via the App’s unified credential set. The App ID is non-secret and lives in the ArgoCD Application valuesObject; only the private key is stored in Vault.

Rationale

• CE configures exactly one App; multi-org coverage therefore requires a public App — a private App cannot be installed by other orgs.
• Install-gating (the org owner must explicitly install) plus least-privilege permissions (Contents/PRs/Issues read-write, Metadata read) bound the trust exposure.
• Adding a future org requires only installing the existing App — no new CE deployment or credential set.

Alternatives Considered

• Single public App, installed per-org (chosen): one CE instance serves all orgs; standard supported CE topology; least-privilege still applies per installation. Cost: the App is publicly discoverable and any account could attempt installation (mitigated by install-gating).
• Private App per org (rejected): tighter isolation, but CE supports only one App, so this forces one CE deployment per org (or unsupported multi-App wiring) — operationally untenable.

Consequences

• Positive: adding a new org is just an App install, not a new CE instance; single credential set and one Vault policy path.
• Negative: the App is publicly discoverable and unauthorized installs are possible (mitigated by install-gating); the bot identity is visible across all orgs it serves.
• Neutral: App ID is non-secret (valuesObject); only the private key is in Vault.