How dependabot works

Summary

GitHub, GitLab, and Gitea all have dependency tracking and automated updates, but in each case the interesting parts are premium or closed source. I wanted to understand how these features could be built openly into something like Forgejo. Dependabot is a key piece of GitHub’s dependency tooling, dependabot-core is MIT licensed, and it’s written in Ruby, so it seemed like a good place to start. Most developers think of Dependabot as a smart bot that watches their repositories and creates pull requests when updates are available. It isn’t one. The codebase is a stateless Ruby library that knows nothing between runs, wrapped by proprietary GitHub infrastructure that handles all the coordination. In May 2024, GitHub relicensed dependabot-core under MIT, replacing the Prosperity Public License that had restricted commercial use. This covers the update logic: parsing manifests, checking registries, generating file changes. The scheduling, state tracking, and coordination that make Dependabot work as a service remain proprietary. Self-hosting means rebuilding those parts yourself. The codebase The repository is 330,000 lines of Ruby supporting 25+ package ecosystems. The naming is idiosyncratic: bundler not rubygems, pip not pypi, npm_and_yarn combined, go_modules not golang, hex not elixir, cargo not crates. This differs from PURL, the newly minted ECMA standard, which uses registry names, and from other tools which use language names. If you are trying to map between systems, expect friction. Each ecosystem implements four core classes: FileFetcher downloads manifest and lockfiles from a repo, FileParser extracts dependencies, UpdateChecker queries registries for new versions, and FileUpdater generates the file changes for a PR. The complexity varies wildly. GitHub Actions FileParser is 194 lines. Gradle is 615. The npm ecosystem spans multiple files handling package.json, various lockfile formats, yarn, pnpm, and workspaces. The npm file_updater_spec.rb test file alone...