Shared Renovate presets for Kong repositories. Use these as building blocks or extend the default preset for a secure, low-noise setup that works across languages and ecosystems.

Use the default preset to get a secure, low-noise setup that works across languages and ecosystems.

Use the floating preset so projects automatically pick up changes:

{
  "extends": ["Kong/public-shared-renovate"]
}

• Renovate does not support digest pinning for presets, so exact tags bring no real security gain
• Presets are config, not executable code, and are loaded by Renovate at runtime
• Floating avoids delays and lets shared preset improvements roll out quickly without waiting for a tag bump in every repo

Pin only when you must hold back or temporarily downgrade because a change breaks your workflow:

{
  "extends": ["Kong/public-shared-renovate@<VERSION>"]
}

If pinned, Renovate will open PRs to bump the preset via the renovate-config-presets manager unless that manager is explicitly disabled. Replace <VERSION> with the specific release tag you want to use from the releases' page (for example, the last known good version if you are downgrading).

A concise summary of the default preset (see default.json for full details):

• Clear PRs and commits: messages show from → to, including short SHAs for digests
• Merge Confidence badges are shown on PRs for extra signal
• Standard labeling: the 'dependencies' label is added to all Renovate PRs
• Extra version discovery via custom managers: Dockerfile ARG versions, Helm Chart appVersion, Makefile versions, and Terraform tfvars
• GitHub Actions kept healthy: grouped sensibly and pinned by commit for security and stability
• Security posture: vulnerability alerts are enabled and surfaced via the base security preset
• Fresh releases are gated briefly by default: minimumReleaseAge is 12 days (override locally as needed)

The labels override always includes the standard 'dependencies' label and appends up to five optional labels you provide.

{
  "extends": [
    "Kong/public-shared-renovate",
    "Kong/public-shared-renovate//overrides/labels(renovate,ci)"
  ]
}

Use the Kong/public-shared-renovate//overrides/reviewers preset to automatically request specific users or teams on Renovate PRs.

• Accepts up to five reviewers as arguments
• Arguments can be either a user (e.g. octocat) or a team using the team: prefix
• When referencing a team, you must use only the last segment of the GitHub team name. For example, if the full team name is @organization/foo, you must pass team:foo
• Place this override after the default preset in extends, as order matters

Example:

{
  "extends": [
    "Kong/public-shared-renovate",
    "Kong/public-shared-renovate//overrides/reviewers(octocat,team:foo)"
  ]
}

You can change how often Renovate runs by adding a schedule preset. Place it after the shared preset so it takes effect — the order of items in extends matters because later entries override earlier ones.

Example:

{
  "extends": [
    "Kong/public-shared-renovate",
    "schedule:daily"
  ]
}

See the options' reference for more: Renovate configuration options

Renovate interprets schedules in a configurable timezone. If no timezone is set in your config, Renovate defaults to UTC. To change the timezone for your consumer repository, extend the builtin timezone preset with an IANA Time Zone (TZ) identifier. Place it after the shared preset in extends so it overrides any timezone configured by presets you include.

Example:

{
  "extends": [
    "Kong/public-shared-renovate",
    ":timezone(America/New_York)"
  ]
}

By default, Renovate uses GitHub's platform automerge. When a PR is eligible and all requirements are met (for example, required status checks pass), Renovate enables auto-merge on the PR and GitHub merges it as soon as conditions are satisfied. There is no schedule involved in this default flow.

If you want automerge to follow a schedule, first disable platform automerge by setting platformAutomerge to false. Then configure a schedule either with automergeSchedule directly or via one of the Renovate schedule presets.

Example using a preset:

{
  "extends": ["Kong/public-shared-renovate", "schedule:automergeWeekdays"],
  "platformAutomerge": false
}

Example configuring manually:

{
  "extends": ["Kong/public-shared-renovate"],
  "automergeSchedule": ["every weekday"],
  "platformAutomerge": false
}

These examples show how to adapt the defaults from security/base.json using security overrides: overrides/security-labels.json and overrides/security-reviewers.json.

Use this if your repository already applies its own risk labels or if you want to reduce visual noise from security PRs. This removes only the security label added by the shared preset for vulnerability alerts. Existing PRs keep their labels; new PRs reflect the change.

{
  "ignorePresets": ["Kong/public-shared-renovate//overrides/security-labels"],
  "extends": ["Kong/public-shared-renovate"]
}

Use this if your team prefers a different label name for security updates or to align with existing dashboards. Pass the desired label as the first argument. GitHub creates the label if it does not exist. Applies to security-scoped updates (vulnerability alerts and security-actions rules). Choose a label your processes already recognize (e.g. sec-critical, security-high).

{
  "extends": [
    "Kong/public-shared-renovate",
    "Kong/public-shared-renovate//overrides/security-labels(sec-critical)"
  ]
}

Use this if you want to keep the standard security label and add another one for routing or automation. Provide up to five labels as arguments, separated by a comma, with no spaces. Order does not matter. Useful for dashboards or rules that depend on labels like ci, platform, or team-specific tags. GitHub creates labels if they do not exist.

{
  "extends": [
    "Kong/public-shared-renovate",
    "Kong/public-shared-renovate//overrides/security-labels(security,ci)"
  ]
}

The minimumReleaseAge setting controls how long Renovate waits before creating a PR for a new version. By default, we enforce a 12-day delay to balance delivery speed with stability and security.

When defined at the root level, this setting applies to all dependencies and update types. For finer control, you can define it inside packageRules to apply the delay only to specific dependencies or groups.

{
  "extends": ["Kong/public-shared-renovate"],
  "minimumReleaseAge": "30 days",
  "packageRules": [
    {
      "matchDepNames": ["left-pad"],
      "minimumReleaseAge": "a billion years"
    }
  ]
}

⚠️ Note: This setting does not apply to updates triggered by vulnerabilityAlerts. Security-related updates always bypass minimumReleaseAge and Renovate will open a PR as soon as a fix is available.

When multiple Renovate presets or rules overlap, Renovate applies settings based on a clear precedence model. Knowing this hierarchy helps avoid surprises and ensures that the intended configuration is actually used.

1. Later extended presets override earlier ones

   • The order in the extends array matters. A preset listed later takes precedence over one listed earlier
   • Example: if both base/go and overrides/labels define labels, the labels from overrides/labels will be applied if it comes after base/go in the list

2. Direct values in a config override inherited presets

   • Any setting defined directly in a repo's renovate.json (or equivalent) always overrides values inherited from presets
   • Example: if a preset sets automerge: false but the repo's renovate.json sets automerge: true, the direct value wins

3. packageRules targeting specific dependencies or versions override direct values

   • packageRules act as more granular overrides for individual dependencies, package managers, or version ranges
   • Example: a repo may set automerge: true globally, but add a packageRule for golang that sets automerge: false. Renovate will follow the more specific rule

4. If multiple packageRules match, the later one wins

   • The order of rules in the array matters. When multiple rules match the same dependency or update, Renovate applies the last matching rule
   • Example: one packageRule may schedule updates daily, while a later one may schedule them weekly. Renovate will use the weekly schedule

Because of this precedence model:

• Presets in overrides/ must be extended after the default (Kong/public-shared-renovate) to take effect
• Helpers are only applied when explicitly added and follow the same rules as other presets
• Scoped or security presets can override base behavior if extended later in the chain

This order of precedence ensures predictability: start with the org-wide defaults, apply scoped or override presets as needed, and finally tune behavior with direct config, and packageRules.

Kong's shared Renovate presets are organized by purpose:

• base/ – reusable building blocks for org-wide policy (Go, GitHub Actions, security, frontend), composed into the top-level default. Most repos just extend the default (Kong/public-shared-renovate).
• overrides/ – small reusable tweaks layered on top of base/ or the default (labels, reviewers, automerge adjustments).
• helpers/ – tiny, standalone utilities usable directly in renovate.json or within other presets.
• scoped/ – rules for a specific product, project, or team, not meant for org-wide use.
• security/ – long-lived security defaults (security/base.json) plus short-lived incident guardrails (security/incidents/).

For detailed guidance, see Choosing the right directory.

Guidance for creating, wiring, and maintaining security-incident presets is documented in the contributor guide. This includes the full process, directory layout, common patterns, examples, and expectations for deprecation and cleanup.