Retrospective: Automating Dependency Updates with Renovate 37.0 at Meta

At Meta, managing dependencies across thousands of internal repositories and monorepos has long been a critical operational challenge. Manual dependency updates consumed hundreds of engineering hours monthly, left security vulnerabilities unpatched for weeks, and caused inconsistent dependency versions across teams. In Q3 2024, we rolled out Renovate 37.0 across our entire codebase, replacing legacy custom tooling with a standardized, automated dependency update pipeline. This retrospective outlines our implementation, results, and key lessons learned.

Pre-Renovate Pain Points

Before adopting Renovate 37.0, our dependency update workflow relied on a patchwork of custom scripts, manual GitHub/GitLab dependency checks, and ad-hoc team processes. Key issues included:

• High manual toil: ~120 engineering hours per month spent triaging, testing, and merging dependency updates across 4,200+ active repositories.
• Security lag: Critical CVE patches took an average of 14 days to reach production, as manual update processes couldn’t scale to our release velocity.
• Dependency drift: 38% of repositories used outdated major versions of core libraries, leading to compatibility issues and duplicated effort across teams.
• PR fatigue: Unstructured update PRs (one per dependency version) flooded team inboxes, leading to ignored updates and stale branches.

Why Renovate 37.0?

We evaluated multiple dependency automation tools, but Renovate 37.0 stood out for its support for our scale and custom requirements. Key 37.0 features that aligned with our needs included:

• Enhanced monorepo support: Native support for Meta’s internal monorepo structures, with per-package update rules and cross-package dependency tracking.
• Smart PR grouping: Configurable rules to group related dependency updates (e.g., all @babel/* updates) into single PRs, reducing PR volume by 62% in initial tests.
• Security advisory integration: Direct integration with our internal CVE database and public NVD feeds, with auto-labeling of security-critical updates.
• Custom regex managers: Support for parsing non-standard dependency files (e.g., internal build configs, custom package manifests) via regex-defined managers.
• On-premise compatibility: Full support for air-gapped deployments, aligning with Meta’s security and compliance requirements.

Implementation Details

We rolled out Renovate 37.0 in three phases over 12 weeks to minimize disruption:

1. Pilot phase: Deployed to 50 low-risk repositories with default configs, collecting feedback on PR formatting, grouping rules, and CI integration.
2. Custom config development: Built a centralized Renovate config preset for Meta, including:
   • Default grouping rules for common dependency ecosystems (npm, PyPI, Maven, Go modules)
   • Auto-assignment of update PRs to owning teams via CODEOWNERS integration
   • Mandatory CI checks for all update PRs, with auto-merge for non-breaking patch updates passing all tests
   • Custom regex managers for 12 internal dependency file formats
3. Full rollout: Deployed to all 4,200+ repositories and 3 core monorepos, with a self-service onboarding portal for teams to override default configs.

We hosted Renovate 37.0 on our internal Kubernetes cluster, with a dedicated service account for repository access and rate limiting aligned with our Git provider’s API quotas. Integration with our internal CI system (Buck2) required custom webhook handlers to trigger dependency update PR checks, which we contributed back to the Renovate open-source project.

Results and Metrics

Six months post-rollout, we measured the following improvements:

• Manual toil reduction: 89% decrease in engineering hours spent on dependency updates, from ~120 hours/month to ~13 hours/month.
• Security response time: Average time to patch critical CVEs dropped from 14 days to 2.1 days, with 94% of security updates auto-merged within 24 hours of release.
• Dependency freshness: 92% of repositories now use the latest minor/patch version of core dependencies, up from 62% pre-rollout.
• PR efficiency: 73% reduction in total update PRs, with grouped PRs having a 41% higher merge rate than single-dependency PRs.

Challenges and Mitigations

We encountered several challenges during implementation:

• False positive security labels: Initial integration with our internal CVE database mislabeled 12% of updates as security-critical. We fixed this by adding a manual review step for security-labeled PRs and tuning advisory matching rules.
• Monorepo update conflicts: Large monorepo updates occasionally caused merge conflicts across packages. We implemented Renovate’s separateMajorMinor rule and added a monorepo-specific grouping rule to batch cross-package updates.
• Rate limiting: Initial deployments hit Git API rate limits when scanning 4,200+ repos. We added exponential backoff to Renovate’s API requests and increased our Git provider’s rate limit quota for the Renovate service account.

Lessons Learned

1. Centralized config presets reduce team onboarding time by 70% compared to per-repo configs.
2. Auto-merge for non-breaking updates requires strict CI gate checks to avoid regressions – we saw a 0.2% regression rate post-auto-merge enablement.
3. Grouping PRs by ecosystem and team ownership is critical to reducing PR fatigue and improving merge rates.
4. Contributing custom integrations (e.g., Buck2 webhooks) back to open source improves tool longevity and community support.

Conclusion

Renovate 37.0 has transformed our dependency update workflow at Meta, eliminating manual toil, improving our security posture, and standardizing dependency management across thousands of repositories. While we faced scaling and integration challenges, the measurable improvements in efficiency and security justify the investment. We plan to extend Renovate’s usage to our mobile and ML codebases in 2025, and contribute additional monorepo and internal tool integrations to the Renovate project.