Dependabot Has No Path to Forgejo or Gitea, and Only a Community Patch for GitLab: Why Renovate Is the Only Bot Built for All Three

Point Dependabot at a self-hosted Gitea or Forgejo server and nothing happens — not a degraded experience, not a manual workaround, just silence, because there is no code path in dependabot-core that knows those servers exist. Point it at self-hosted GitLab and there's a fix, technically: a community-run Rails app called dependabot-gitlab that wraps GitHub's own dependency-update logic and re-implements the coordinator GitHub never shipped for anyone else. It works. It's also been a side project maintained outside GitHub since before most of today's Dependabot users started using it.

That's the deliverable up front, because the gap is easy to understate as "Dependabot is GitHub-only" and move on: it's not one gap, it's two, and they're different sizes. GitLab gets a real, if unofficial, patch. Gitea and Forgejo get nothing — no patch, no wrapper, no path. Renovate, by contrast, runs natively on all of them, plus Bitbucket and Azure DevOps, out of the same self-hosted binary. For a platform whose own docs already point tenants who don't want GitHub toward Forgejo, that second gap isn't a minor inconvenience. It's a dependency-automation dead end sitting directly behind a recommendation the platform made itself.

The Platform-Support Gap, Concretely​

Dependabot's official platform support begins and ends with GitHub — GitHub.com and GitHub Enterprise Server, full stop. Renovate ships as a self-hostable CLI and Docker image that talks natively to GitHub, GitLab (SaaS and self-managed), Bitbucket, Azure DevOps, Gitea, and Forgejo, with experimental support for Gerrit and AWS CodeCommit on top. There's no separate product tier or wrapper needed to point Renovate at a self-hosted Forgejo instance — it's one of the platforms the core tool already speaks.

Why Dependabot Can't Cross the Wall​

The limitation isn't an oversight GitHub could patch in a changelog entry — it's structural. Dependabot's coordinator, the piece that opens pull requests, schedules runs, and talks to a git host's API, is built around GitHub's own App and API model. There's no official self-hosted mode and no supported CLI you point at an arbitrary git server. GitHub open-sourced dependabot-core under MIT in 2024, so the underlying update logic (working out what a new dependency version is, generating the diff, writing the PR body) is available to reuse. But reusing the logic isn't the same as having a runner: GitHub issue #10898, asking for HTTP support so Dependabot's core could talk to "private, self-hosted project management systems like GitLab," has been open for years with no shipped resolution from GitHub itself.

That's the wall every non-GitHub self-hoster runs into: the logic is open, but the coordinator that would let it run against your own Forgejo server was never built, and building it isn't GitHub's problem to solve when its entire product is sold as part of GitHub.

The GitLab Patch That Exists, and the Forgejo Patch That Doesn't​

Because dependabot-core's logic is reusable, someone else could — and did — build the missing coordinator for one platform. dependabot-gitlab is a community-maintained Rails application that wraps dependabot-core and re-implements what GitHub's own coordinator does, aimed specifically at self-hosted GitLab. It's a real, working project, and it's the reason "Dependabot doesn't run on GitLab" is the wrong way to describe the gap — a maintained third-party bridge exists, run by volunteers, entirely outside GitHub's own support surface.

No equivalent exists for Gitea or Forgejo. The older community effort in this space, dependabot-script, has carried a broken warning since March 2023. There is currently no maintained project — official or community — that gets Dependabot's update logic running against a Gitea or Forgejo repository. If a team's git host is Forgejo, Dependabot isn't a degraded option; it's not an option.

That distinction matters directly here, because a self-hosted PaaS whose own docs already recommend Forgejo to tenants who don't want to run on GitHub just steered them onto the one platform where Dependabot has no path at all — not even an unofficial one.

What Renovate Covers That Dependabot Doesn't​

Platform reach is the headline gap, but it's not the only one. Renovate supports more than 90 package ecosystems — npm, Yarn, pnpm, Bun, pip, Poetry, uv, Maven, Gradle, sbt, Go modules, Cargo, Composer, Bundler, Terraform, Helm, Kubernetes manifests, Docker, Docker Compose, GitHub Actions, GitLab CI, and a regex-based custom manager for anything else with a version string in a file. Dependabot's own supported-ecosystems documentation lists roughly 31 — a real and growing list (Nix flakes landed in April 2026, sbt in May 2026), but still under a third of Renovate's coverage. uv, the Rust-based Python package manager that's seen fast adoption since 2024, is on Renovate's list today and isn't yet on Dependabot's.

Two feature gaps compound the platform-coverage gap:

• Dependency Dashboard. Renovate opens a single, persistent issue in the repo summarizing every pending, in-progress, and gated update, with checkboxes that let a maintainer trigger a major-version PR on demand instead of getting it unprompted. Dependabot has no equivalent — every eligible update just becomes a PR, with no single place to see the whole backlog at a glance.
• Automerge. Renovate has automerge as a first-class config option: set "automerge": true on a package rule (by update type, by package name, gated on CI passing) and it merges without further action, including a branch-automerge mode that skips opening a PR at all for low-risk bumps. Dependabot has no built-in automerge — teams wire it up themselves with the dependabot/fetch-metadata GitHub Action reading the PR's update-type label, then a workflow step running gh pr merge --auto. It's a supported pattern, but it's a workflow a team assembles, not a setting it flips.

What This Actually Means for a Self-Hosted, Git-Agnostic Platform​

None of the above is an argument against Dependabot on GitHub — it's free, it ships zero-config, and its native GitHub security-advisory integration is genuinely good at what it does. The argument is narrower: a platform that tells tenants their repo doesn't have to live on GitHub can't quietly assume dependency automation works the same way regardless of where that repo actually lives. If the platform's own onboarding docs point a non-GitHub tenant toward Forgejo, and that tenant later asks "how do I get automated dependency PRs," the honest answer today is "Dependabot can't reach you here — you want Renovate," not silence, and not a shrug that leaves the tenant assuming automated updates are a GitHub-only convenience they gave up by choosing self-hosted git.

Concretely, that leaves two levels a self-hosted PaaS can act on, and they're not mutually exclusive:

1. Recommend. Ship a starter renovate.json in scaffolded project templates and document the five-minute self-hosted setup — a token with repo/write scope and a scheduled job (cron, systemd timer, or a Kubernetes CronJob on the same Cluster-API-managed fleet already running the tenant's app) invoking renovate against the tenant's Forgejo repos. This costs nothing to build and closes the awareness gap: a tenant who'd never heard of Renovate now has a working config instead of an assumption that dependency bots don't exist outside GitHub.
2. Bundle. Run Renovate as a platform-operated service — one shared job iterating tenant repos on the platform's own Forgejo instance, using per-tenant tokens scoped to their own repos, so "turn on dependency updates" becomes a checkbox in the platform UI instead of infrastructure a tenant stands up themselves. This is more platform surface to operate (queueing, per-tenant rate limits, config isolation) but turns dependency automation from "something the platform's docs point you toward" into a feature the platform actually ships.

Either path is more honest than the default a lot of self-hosted PaaS platforms fall into without deciding to: quietly assuming most tenant repos live on GitHub, because that's where Dependabot already works, and letting a Forgejo tenant discover the gap on their own.

Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own, with a Render-compatible API on top and no assumption that your repo has to live on GitHub. Check out the repo on GitHub if "self-hosted" should mean the whole toolchain, not just the deploy target.

Sources​

• GitHub Dependabot supported ecosystems and repositories
• Renovate self-hosting examples
• Renovate bot comparison docs
• dependabot-core GitHub issue #10898: HTTP support for self-hosted GitLab-like servers
• dependabot-gitlab project
• Dependabot version updates now support the Nix ecosystem
• Dependabot version updates now support the sbt ecosystem