Dependency Management at Scale: How To Maintain 200+ Infrastructure Tools Up to Date
If you’ve ever maintained a large-scale infrastructure, you know that every week brings a stream of new updates in cloud-native tooling.
Some come packed with security fixes, while others introduce breaking changes that can silently disrupt your deployments.
What you might also know is that manually tracking Helm chart updates, Terraform provider changes, or dependency shifts doesn’t scale.
Missing a fix for a CVE vulnerability? Probably not something you want.
So, how does one stay up-to-date without turning tooling updates into a full-time job?
As an SRE, I worked on various projects consisting of 200+ dependencies, if not more.
While most patch updates weren’t concerning, manually visiting and tracking updates across different tools was simply out of the question.
So the goal was pretty obvious—automate it.
At least to the point where tool version updates would automatically suggest changes in code repositories in the form of Pull Requests.
For such task, Dependabot is a pretty popular choice, but I haven’t find it fitting my needs.
The problem?
It’s tied to GitHub, while some of the clients projects were using BitBucket or GitLab.
Neither does it support self-hosting.
While there are workarounds to make this work, I didn’t want to spend much time on it since I believed such a solution should already exist.
Luckily, there’s Renovate and I really liked it.
The Renovate documentation already provides a solid overview of its capabilities, so give it a read if your a new to this, I rather want to focus why I liked it so much.
First off, Renovate provides a self-hosted solution out-of-the-box and one can easily track dependencies across different project — be it on GitHub, BitBucket or GitLab.
I think self-hosting it and keeping track of dependencies “in-house” is really important.
I really didn’t want to end up in a situation where there’s a leak, attackers know which libraries and versions you utilize, and consequently, the infrastructure becomes vulnerable to specific attacks.
And if it would happen, this would be on me.
Pretty delicate topic.
It is also utilized by a range of well-known companies, which is really important when choosing an open-source tool. Everyone wants to see the tool improve over time, but if there aren’t enough users, quite the opposite can happen.
To be frank, at first it was quite challenging to break through all of its features, but eventually, it got it working nicely on the Kubernetes cluster.
Let me show you how.
Deploying Renovate on Kubernetes
For the following steps, I’ll assume you already have a running Kubernetes cluster.
Setting up Renovate involves three configuration files:
Cronjob: In addition to referencing the configuration, this file defines how often Renovate should execute.
Secret: This manifest configures Renovate, including setting up the GitHub access token, specifying which repositories to monitor, and other relevant settings.
💡Note: You might not want to commit this secret in plain text to your VCS. If you’re interested in how to encrypt it, check out my previous post.
After this, the only remaining step is to instruct Renovate on what to look for in the referenced repositories.
This can either be done at a global level as part of the Renovate configuration or per repository.
It’s up to you, but for the sake of this example, I’ll show you how it’s done at the repository level.
Initially, Renovate generates a pull request (PR) for every repository you’ve configured to track dependencies.
This PR creates a simple renovate.json file.
Through this file, you can override global configuration values and instruct Renovate on how to manage dependencies in that specific repository.
💡 If you decline the PR, Renovate will disregard the repository for any future updates.
An example configuration might look like this:
With this simple configuration, Renovate searches for kustomization.yaml files inside your repository and generates pull requests exclusively for major and minor updates of detected packages.
While we’ll stop here, there’s a lot more to it.
Just think about a scenario where you have 200+ updates, and each week at least a dozen new releases come out.
Being overwhelmed by a constant stream of updates can be exhausting—not to mention that over time, you might just stop keeping up because it takes too much time.
In the upcoming post, I’ll talk about how to nurture a culture of automation in the team and share some neat configuration tips to reduce this workload as much as possible.
⏪ Did you miss the previous issues? I'm sure you wouldn't, but JUST in case:
I hope you find this resource helpful. Keep an eye out for more Cloud updates and developments in next week's newsletter.
Until then, keep 🧑💻-ing!
Warm regards, Teodor
Recently I had to upgrade two major versions of Renovate with many breaking changes (eg. Fields removed).
Renovate created config migration PRs automatically and it even silently applied those migrations before those PRs were even merged.
No downtime at all.
Very smooth