Create your renovate.json configuration with ease
What it does: Your renovate.json will automatically include these baseline presets:
config:recommended - Sensible defaults for most projects: pin GitHub Actions to digests, group monorepo packages, use semantic commit messages for major updates, and more. :enableVulnerabilityAlerts - Automatically creates PRs for security vulnerabilities detected by your platform's security advisories (GitHub Dependabot, GitLab, etc.). :dependencyDashboard - Creates a special issue that lists all pending updates, rate-limited updates, and provides manual approval controls. Why you want this:
What it does: Formats all Renovate commit messages and PR titles according to the Conventional Commits specification (e.g., fix(deps):, chore(deps):).
Why you want this:
fix: prefix for production dependencies and chore: for development dependenciesWhat it does: Sets the timezone for Renovate's schedule. When you configure schedules (like "run updates only during weekends" or "between 10pm-6am"), times are interpreted using this timezone.
What it does: Controls when Renovate is allowed to create or update PRs. Helps minimize disruption by scheduling updates during low-activity periods.
Why you want this: Prevents PR noise during working hours. "Weekends" and "Weeknights" are popular choices to keep updates out of the workday.
Note: Security vulnerability alerts will always override this schedule to ensure immediate patching.
Control how many PRs Renovate creates to avoid overwhelming your team and CI resources.
Renovate's default settings: Up to 2 PRs per hour, max 10 open PRs at once. Good for most teams with regular review capacity.
Conservative limits: 1 PR per hour, max 3 open PRs. Perfect for small teams or projects with limited CI resources.
Aggressive limits: 10 PRs per hour, max 20 open PRs. For teams that can quickly review and merge updates, or have robust CI pipelines.
What it does: Controls the rate and volume of PRs Renovate creates via prHourlyLimit (PRs per hour) and prConcurrentLimit (max open PRs).
Why you want this: Prevents CI overload, makes reviews manageable, and integrates with Renovate's Dependency Dashboard to show queued updates.
Control when Renovate rebases its branches to keep them up-to-date with your base branch.
Renovate's default: Auto-detects the best strategy. Keeps branches up-to-date if automerge is enabled or your repo requires it.
Rebase only when merge conflicts occur. Reduces CI load if you have many concurrent PRs. Good for busy repositories.
Rebase whenever the branch is behind base by 1+ commits. Ensures PRs are always current, but increases CI runs.
Never automatically rebase. You'll need to manually trigger rebases. Not recommended for most use cases.
What it does: Controls when Renovate updates its PR branches to incorporate new commits from your base branch (like main).
Why you want this: Balances keeping PRs current with managing CI costs. "Smart" works for most teams, "Only When Conflicted" helps if rebases are slowing Renovate down.
Control how Renovate updates version ranges in your package files (e.g., ^1.0.0 vs 1.0.0).
Let Renovate decide the best strategy based on your project type and dependencies.
Only update ranges when new version falls outside. Example: ^1.0.0 → ^2.0.0. Conservative approach.
Explicitly update ranges for every change. Example: ^1.0.0 → ^1.0.1. Makes all updates visible in package.json.
Update lockfiles without changing package.json ranges. Ranges stay as-is, only resolved versions change. Good for keeping stable ranges.
Remove all ranges and use exact versions. Example: ^1.0.0 → 1.0.1. Maximum control and reproducibility.
What it does: Determines how Renovate modifies version constraints in your package.json, composer.json, or similar files when updating dependencies.
Why you want this: Controls the balance between stability (conservative ranges) and visibility (explicit updates). "Replace When Needed" is often the safest choice.
Choose how Renovate should automerge updates when automerge is enabled (requires separate automerge configuration).
Create PRs and automerge them after tests pass. Full visibility with notifications. Works with all branch protection rules.
Merge directly to base branch without creating PRs. Silent updates with only commits visible. Creates PR only if tests fail. Requires branch protection to allow Renovate pushes.
Use with external merge bots like bors-ng. Renovate adds a comment to trigger your bot. Only use if you have a merge bot configured.
What it does: Controls how Renovate performs automerges. "Pull Request" creates visible PRs, "Silent Branch Merge" commits directly for minimal noise.
Why you want this: "Pull Request" provides full visibility and audit trail. "Silent Branch Merge" reduces notification noise for trusted dependencies but requires compatible branch protection.
Automatically merge dependency updates that pass tests. Choose what types of updates to automerge.
No automatic merging. All updates require manual review and approval. Safest option with full control.
Automerge only patch updates (e.g., 1.2.3 → 1.2.4). Most conservative automated approach. Good for risk-averse teams with good test coverage.
Automerge patch and minor updates (e.g., 1.2.3 → 1.3.0). Most common recommendation. Major updates still require manual review.
Automerge all updates including major versions. Aggressive approach requiring excellent test coverage. Only use if you have comprehensive automated tests.
Automerge all devDependencies updates (build tools, linters, test frameworks), regardless of update type. Works independently from the level setting above. Production dependencies follow the level setting.
Automerge immediately without waiting for status checks or test results. Not recommended - only use if your repository has no test suite.
Never automerge dependencies with version 0.x (e.g., 0.5.2, 0.12.4). Recommended for safety - pre-1.0.0 packages can introduce breaking changes at any time.
What it does: Enables automatic merging of PRs that pass all tests. Uses packageRules to control which update types are automerged.
Why you want this: Reduces manual work for safe updates. Most teams use "Patch + Minor". Requires good test coverage to be safe.
Example: If you select "Patch Updates Only" and check dev dependencies, you'll get patch updates automerged for production dependencies AND all updates automerged for dev dependencies.
Wait a specified period after a new version is released before Renovate creates an update PR. Helps avoid cutting-edge releases that might be unstable.
Update to new releases immediately. Renovate's default behavior. Get updates as soon as they're available.
Wait 3 days after release. Short stabilization period to catch immediate bugs. Good balance for most teams.
Wait 1 week after release. Gives the community time to discover issues. Recommended for stability-focused teams.
Wait 2 weeks after release. Conservative approach for maximum stability. Best for risk-averse production environments.
What it does: Delays update PRs until a package version has been published for at least the specified duration. The timer starts from the package registry's published timestamp.
Why you want this: Reduces risk of adopting releases with critical bugs or breaking changes. Lets early adopters discover issues first. Particularly valuable for production dependencies.
Security Best Practice: This configuration will automatically include a rule to bypass the delay for vulnerability alerts, ensuring critical security patches are applied immediately.
Periodically refresh lock files (package-lock.json, yarn.lock, etc.) to update all dependencies, including transitive ones, even when package.json hasn't changed.
Automatically merge lock file maintenance updates if tests pass. This is the lowest-risk type of automerge.
What it does: Regenerates lock files from scratch to update all dependencies (including indirect/transitive ones) to their latest compatible versions. Similar to deleting your lock file and running npm install fresh.
Why you want this: Lock files can accumulate outdated transitive dependencies over time. This ensures everything stays current, even dependencies you don't directly control. Lowest-risk automerge candidate.
Already enabled by default with :enableVulnerabilityAlerts. Configure additional options below.
Comma-separated labels to add to vulnerability alert PRs. Default: "security"
Explicitly set schedule to "at any time" to ensure vulnerability PRs are never delayed by other schedule configurations. Recommended if you have custom schedules elsewhere.
Automatically merge security vulnerability updates if tests pass. Ensures fast patching of security issues.
What it does: Vulnerability alerts bypass normal schedules and rate limits to create PRs immediately when security issues are detected. Adds [SECURITY] suffix to commit messages.
Why you want this: Critical security patches should be applied as soon as possible, not wait for your regular update schedule. GitHub Dependabot alerts are automatically detected.
Group all updates from the same package manager into a single PR to reduce noise. Select which package managers you want to group.
What it does: Groups all updates from each selected package manager into a single PR instead of creating separate PRs for each dependency update.
Why you want this: Reduces PR noise significantly. For example, instead of 15 separate PRs for npm updates, you get 1 grouped PR titled "All npm updates".
{
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"extends": [
"config:recommended",
":enableVulnerabilityAlerts",
":dependencyDashboard",
":semanticCommits"
],
"timezone": "Europe/Berlin",
"prHourlyLimit": 10,
"prConcurrentLimit": 20,
"rebaseWhen": "behind-base-branch",
"rangeStrategy": "bump",
"automergeType": "branch",
"packageRules": [
{
"automerge": true,
"matchUpdateTypes": [
"minor",
"patch"
]
},
{
"matchCurrentVersion": "/^0\\./",
"automerge": false
}
],
"lockFileMaintenance": {
"enabled": true,
"schedule": [
"at any time"
],
"automerge": true
},
"vulnerabilityAlerts": {
"labels": [
"security"
],
"schedule": [
"at any time"
],
"automerge": true
}
}