Host one shareable preset in a repository, then have every service's renovate.json extend it. Change the preset once and every repo that extends it picks up the new rules, so dependency update policy lives in one reviewed place.
What a preset is
Renovate's documentation describes presets as reusable configuration that you pull in with the extends array, and says presets can be nested. Shareable presets must be written in JSON, JSONC or JSON5. They are meant to be hosted in repositories, which usually means the same platform host Renovate runs against, though Renovate can also fetch preset files from an HTTP server.
One detail to check in your setup: the documentation says npm-based presets are deprecated and planned for removal, so host yours in a repository instead.
A typical onboarding config is small. The docs show a renovate.json that extends config:recommended. In a platform setup, the service file shrinks to one extends line that points at your organization preset.
Steps for a platform team
- Create a repository for presets, owned by the platform team with required review.
- Start with a default preset that extends the recommended base and adds your decisions: schedule, grouping, labels, and package rules.
- Add named variants, for example one for services with a stricter policy. Renovate lets a repo host one or more presets, and a name omitted from the reference resolves to a default file.
- Put one extends line in the service template, pointing at the default preset.
- Roll out to existing repos with a bulk pull request that adds the same line.
- Document how a team overrides a single setting locally without forking the preset.
What belongs in the shared preset
| Decision | Put it in the preset because |
|---|---|
| Update schedule | Predictable review load across teams |
| Grouping rules | Fewer, more useful pull requests |
| Rules for internal packages | You own those and can treat them differently |
| Labels and reviewers conventions | Makes pull requests routable |
| Automerge boundaries | Set once, audited once |
Leave service specific choices, such as which directories to ignore, to each repo.
Changing a preset safely
A shared preset is a high leverage file. A bad edit lands in every repo at the next run, and the result can be hundreds of unwanted pull requests.
- Require review from two people for changes to the preset repository.
- Test changes against a small set of pilot repos first, using a branch reference if your setup supports it.
- Announce changes in the channel teams already read.
- Keep a changelog in the preset repository, short and dated.
For the general idea of versioning shared pipeline pieces, see version and roll out changes to a shared pipeline template.
Presets do not decide what is risky
An update tool opens pull requests for newer versions. It does not tell you whether a vulnerable function is reachable in your code, and it does not enforce anything by itself. Pair the preset with merge gates.
Where Safeguard fits
Safeguard applies policies and gates to pull requests and uses reachability analysis to prioritize findings, whichever tool opened the pull request. Try a free scan at gold.safeguard.sh/scan.
Try it yourself
Open a pull request in the demo and watch the gate decide, which is the step an update preset leaves to you.
Click through it at your own pace, or open it full screen.
Quick check
Can a preset live in the same repository as the services?
Presets are repo hosted, and you can host one or more per repository, but a dedicated repository with required review is easier to govern.
Should we publish presets through npm?
Renovate's docs say npm-based presets are deprecated, so use a repository.
Sources
Last reviewed: 19 October 2026.
