# Performing per-environment staged rollouts of dependency updates with Renovate

DevFeed: [Performing per-environment staged rollouts of dependency updates with Renovate](<https://devfeed.tech/articles/performing-per-environment-staged-rollouts-of-dependency-updates-with-renovate-53101.md>)

Original publisher: [Read original article](<https://www.jvt.me/posts/2026/09/08/renovate-staged-branches/>)

Author: Jamie Tanna

Published: 2026-09-08T22:00:11Z

Content type: tutorial

Language: en

Sources: [Jamie Tanna](<https://devfeed.tech/sources/articles-on-jamie-tanna-software-engineer.md>)

Topics: [renovate](<https://devfeed.tech/topics/renovate.md>), [GitOps](<https://devfeed.tech/topics/gitops.md>), [Pull Request](<https://devfeed.tech/topics/pull-request.md>), [forgejo](<https://devfeed.tech/topics/forgejo.md>), [nginx](<https://devfeed.tech/topics/nginx.md>)

Tags: [blogumentation](<https://devfeed.tech/tags/blogumentation.md>), [dependency](<https://devfeed.tech/tags/dependency.md>), [forgejo](<https://devfeed.tech/tags/forgejo.md>), [gitops](<https://devfeed.tech/tags/gitops.md>), [renovate](<https://devfeed.tech/tags/renovate.md>), [review](<https://devfeed.tech/tags/review.md>), [updates](<https://devfeed.tech/tags/updates.md>)

## AI overview

This tutorial explains how to use Renovate to stage dependency updates across environment branches such as dev, staging, and production. It covers base branch patterns and custom datasources and managers that keep versions aligned as updates are promoted.

## Source excerpt

🤖 This post includes some LLM-derived content 🤖 In a lot of organisations, you'll find a fairly consistent structure in teams' (GitOps) repositories, where they set up a branch per deployable environment, such as: * dev * staging * prod Within this structure, the approach for releasing upgrades would be to stage/promote upgrades through environments, starting with dev, through staging and up to prod. If you're using Renovate - which I have been recommending long before it became my job - you can handle this same workflow very nicely. Today, I learned a new couple of tricks to make this work even nicer from Renovate maintainer Michael Kriese, who's been working on this setup upstream with the Forgejo maintainers, where it's been working very well for the team. Prerequisites As a starting point, you would want to set up your repository with baseBranchPatterns to make Renovate manage each of the branches you use, i.e. { "$schema": "https://docs.renovatebot.com/renovate-schema.json", "baseBranchPatterns": ["$default", "dev", "staging", "prod"] } When you specify baseBranchPatterns, you'll start seeing that PRs raised by Renovate are i.e. titled chore(deps): update nginx docker tag to v1.27.3 (dev), which makes it easier to know which of your PRs are for which environment. This minimal config actually gets you quite far towards this setup, and you could probably stop here. But one thing you'll find is that - depending on how long your release pipelines take - in the time it takes for you to release a PR to dev and staging, when it comes to the release to prod, there may now be a new version of the dependency available. This is more of an issue with fast releasing packages - like with Renovate itself - but happens often enough that it can scupper your plans, as you go to review the PR for prod, and the PR updates to the new version, which restarts the release-and-testing flow. Ensuring that these versions can only be rolled out in a specific order is the key problem we're