# dependabot-core: the Ruby library behind Dependabot update PRs > dependabot-core is the library that generates dependency update diffs for a long list of ecosystems. It is a library, not a service, so you bring the entrypoint, the isolation and the pull request wiring. **dependabot/dependabot-core** — 🤖 Dependabot's core logic for creating update PRs. - Repository: https://github.com/dependabot/dependabot-core - Website: https://docs.github.com/en/code-security/dependabot - Stars: 5,789 · Forks: 1,532 - Language: Ruby - License: MIT - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/dependabot-dependabot-core ## What dependabot-core actually does, and who needs it The README calls this repository the library at the heart of Dependabot security and version updates, and the description is literal: it produces update pull requests, and it is consumed by something else. If you enable Dependabot on GitHub.com or GitHub Enterprise by checking a dependabot.yml file into your repository's .github directory, you never touch this code. The library matters when you want a custom version of Dependabot, or you want to run it on another platform. The platform list in the README is GitHub, GitHub Enterprise, Azure DevOps, GitLab, BitBucket and AWS CodeCommit. That is the audience: teams whose repositories live somewhere other than GitHub, or teams that want Dependabot's update logic inside their own CI. The ecosystem list is broad, covering Ruby, JavaScript, Python, PHP, Dart, Elixir, Elm, Go, Rust, Java, Julia and .NET, plus git submodules, Docker files, Opentofu, Terraform files and Pre-Commit hooks. The top-level directories mirror that list, with bundler, cargo, npm_and_yarn, go_modules, docker, helm, nix and others sitting side by side. What the library promises is narrow and specific. It checks for the latest version of a dependency that is resolvable given the project's other dependencies, generates updated manifest and lockfiles for that version, and writes PR descriptions that include the dependency's changelogs, release notes and commits. The third item is the part people underestimate: resolution against the existing dependency set is the difference between an update that applies and one that breaks the build. ## How the update logic is split across ecosystems The repository layout is the architecture. Each ecosystem gets a top-level directory, and the shared machinery lives in common/. A typical ecosystem directory holds the file parsers, the update checkers and the file updaters for that package manager, and the common directory holds what every ecosystem needs: the update runner, the file fetcher, the pull request creator, the dependency and requirement models. That split explains the contribution rules. NEW_ECOSYSTEMS.md exists as a guide because adding a package manager means writing a new set of classes against the common interfaces rather than patching a central switch. ECOSYSTEM_FAMILIES.md groups the ecosystems, and MAINTENANCE_STANDARDS.md sets expectations for the ones already there. The Gemfile, Gemfile.lock, .ruby-version and dependabot-core.gemspec confirm the runtime: this is a Ruby gem, so any wrapper you write is a Ruby program that depends on it. The container side is visible too. Dockerfile.updater-core and Dockerfile.development sit at the top level, docker-bake.hcl drives the image builds, and the omnibus directory holds the packaging that turns the library into a runnable updater image. The README explains why the container matters: Dependabot assumes it is running in an isolated, throw-away environment, and if you write your own wrapper you have to handle that yourself, including protecting against arbitrary code execution exfiltrating credentials and ensuring the right version of Go, Python or whatever language is available. That is not a footnote. Package managers execute project code during resolution, so the isolation is part of the design, not an operational nicety. ## Installing dependabot-core and running a first update with the CLI The README does not give a gem install command. It points standalone users at the open-source Dependabot CLI at github.com/dependabot/cli, described as the recommended entrypoint for standalone use, and used in production at GitHub. The CLI creates dependency diffs but does not create PRs; the example-cli-usage repository shows how to turn those diffs into actual pull requests. If you want the library itself rather than the CLI, the repository is a Ruby gem defined by dependabot-core.gemspec, so a wrapper project would depend on it through Bundler in the usual way. The README's warning applies here: you are responsible for the throw-away environment and for the language runtimes the update needs. The development path is documented separately. The README's Development Guide covers getting a development environment running, debugging problems, running tests and profiling, and the repository ships a .devcontainer directory and a devcontainers directory for that purpose. The development container is the intended way to work on the library, because the ecosystem directories need many language toolchains present at once. One detail is easy to miss and useful in CI. The README states that when Dependabot runs in a container, you can branch your build or installation process on the existence of the DEPENDABOT environment variable. A wrapper that behaves differently inside the updater container can check it directly. ## The isolation requirement is the real cost of self-hosting The strongest limitation in the README is not a missing feature. It is the sentence that Dependabot assumes it is running in an isolated, throw-away environment, so a custom wrapper must handle all of that itself. Resolution and lockfile generation for many ecosystems run the package manager, and package managers run code from the registry. That means a self-hosted setup needs a disposable container per update, a way to keep credentials out of reach of that container, and a way to recover when the update modifies its own runtime environment, which the README lists as a case you must handle. This is where the CLI's scope matters. It produces diffs. It does not open pull requests. Anyone expecting a drop-in replacement for the hosted service has to build the PR layer, the scheduling and the failure reporting, which is exactly what example-cli-usage demonstrates rather than provides as a product. There is a second boundary around the issue tracker. The README is explicit that the tracker is for issues about Dependabot's updating logic, and that questions about security alerts or the Dependency Graph belong in Code Security discussions. It also states that most bug reports should come with a link to a public repository that reproduces the problem, and that reports which cannot be reproduced on a public repo using the CLI tool or the dry-run script may be closed as cannot reproduce. If your update problem only appears against a private registry, you have a harder path to a fix. ## dependabot-core compared with Renovate The comparison people search for is Dependabot versus Renovate, and the architectural difference is the useful part. Renovate is a self-contained tool you run yourself; dependabot-core is a library that the hosted Dependabot service and the Dependabot CLI both build on. Choosing dependabot-core means choosing to assemble a runner, whether that is the CLI plus your own PR wiring, or a Ruby wrapper around the gem. The trade-off follows from that. A library gives you the exact update semantics GitHub uses in production, which the README states directly about the CLI, and it gives you the ecosystem coverage listed in the repository. What it does not give you is an opinion about how updates are scheduled, where credentials live or how failures surface. Those decisions are yours, and the README warns they include the security-sensitive ones. There is also a middle option worth naming. If your repositories are on GitLab, the related search term Dependabot-gitlab points at the pattern of running this logic against a non-GitHub host, which is precisely the standalone use case the README describes. The library supports opening pull requests against GitLab, BitBucket, Azure DevOps and AWS CodeCommit, so the host is not the blocker. The blocker is the operational work around the update. ## Maintenance, releases and what the MIT licence leaves to you The repository is not archived, and the last push was on 2026-09-22. Releases are frequent and versioned in the 0.x range: v0.397.0 on 2026-09-21, v0.396.0 on 2026-09-14 and v0.395.0 on 2026-09-07, roughly weekly. Two changelog archives at the top level, CHANGELOG_ARCHIVE_2017_TO_2018.md and CHANGELOG_ARCHIVE_2019_TO_SWITCH_TO_GITHUB_RELEASES.md, record the switch to GitHub releases as the changelog home. The upgrade cost for a wrapper is tied to the 0.x versioning. Pinning to a minor line and reading release notes before moving is the conservative approach for a gem that resolves dependencies on your behalf. The repository also carries .rubocop.yml, .rubocop_todo.yml, .codespellrc and .yamllint.yaml, which tell you the contribution style if you plan to send patches rather than only consume them. The licence is MIT, which is permissive and short. It does not, by itself, answer the questions a self-hosted deployment raises: whether running package manager code from public registries fits your security model, how long you retain the credentials the updater uses, and who is accountable when an update merges a compromised release. Those are deployment decisions, not licence terms, and nothing in the repository makes them for you. The README's security policy points vulnerability reports at the GitHub Bug Bounty program rather than a private disclosure address. ## Conclusion Adopt dependabot-core when you need update logic for an ecosystem GitHub's hosted service does not cover, or when you want to run the updater on GitLab, BitBucket, Azure DevOps, AWS CodeCommit or your own CI. Do not adopt it if you just want version updates on a GitHub repository: checking a dependabot.yml into .github gets you the hosted service with no library, no container and no credential handling of your own. Before committing, verify three things: that your target ecosystem appears among the top-level directories (bundler, cargo, npm_and_yarn, go_modules, docker and the rest), that you can run each update in a throw-away environment because the README states Dependabot assumes exactly that, and that you have somewhere for the diffs to go, since the CLI creates dependency diffs but does not create PRs. ## FAQ ### What is dependabot-core and how does it work? It is the Ruby library at the heart of Dependabot security and version updates. It checks for the latest version of a dependency that is resolvable given the project's other dependencies, generates updated manifest and lockfiles, and writes PR descriptions containing the dependency's changelogs, release notes and commits. ### Is dependabot-core owned by GitHub? It lives in the dependabot organization on GitHub and the homepage points at GitHub's documentation. The README describes the CLI as used in production at GitHub, and the security policy directs vulnerability reports to the GitHub Bug Bounty program. ### Is dependabot-core free to use? The repository is licensed under MIT. That covers the code in this repository; the README does not describe pricing for the hosted Dependabot service, so cost questions about GitHub.com or GitHub Enterprise are outside what this material states. ### Is dependabot-core reliable? It is the library behind the Dependabot service, and the README states the CLI is used in production at GitHub. Reliability of a self-hosted setup depends on the isolation you provide, since the README says Dependabot assumes a throw-away environment and a custom wrapper must handle that itself. ## Sources - [dependabot/dependabot-core on GitHub](https://github.com/dependabot/dependabot-core) - [License: MIT](https://github.com/dependabot/dependabot-core/blob/main/LICENSE) - [Project website](https://docs.github.com/en/code-security/dependabot) - [README](https://github.com/dependabot/dependabot-core/blob/main/README.md) - [Releases](https://github.com/dependabot/dependabot-core/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dependabot-dependabot-core