Dependabot cannot update this dependency (Private Registry)

Using the .dependabot/config.yml file for configuring Dependabot on our projects that use private registries such as works fine, but when using the .github/dependabot.yml file instead, GitHub says:

“Dependabot doesn’t support updating dependency files that use private package registries.”

Do we know if there will be support for this in the future? Is there action I can take now to make it work in the mean time?


Hi @zachwright,
Welcome to the community! We’re working adding private registry support over the coming months. For now, I would recommend you keep using Dependabot Preview. You can migrate back by removing the new config file and adding the repository in


Also waiting for this. Is this any time frame?

Would really like an update… I migrated from dependabot-preview to dependabot but now it won’t update the packages

1 Like

GitHub announced yesterday that Dependabot now supports private repositories. I tried this today with an npm package associated with a private repository with no luck. I suspect it works with private repositories (as in: a dependency which is a GitHub URL for a private repo) and not for packages in private repositories. I’ve filed a feedback hoping for some clarification, hopefully in the form of some update in the documentation.


Hi there,

Despite this blog post, the documentation still shows both private registries and private repositories not being supported. Plus, the public roadmap issue for this feature was closed with label shipped for only 4 days: it’s now reopened, the shipped label has been removed, but it’s still in the “Q4 2020” column of the public roadmap. Plus, and that’s the biggest one: old Dependabot app seems to have stopped supporting private repositories (at least in my case, for a Python/pip project requiring private Github repositories), which invalidates @andreagriffiths11’s answer.

Can we have some piece of information about:

  • The scope of this feature: Private registries? Private repositories? Both?
  • What happened? Was the feature deployed then rolled back?
  • What’s going to happen now on that matter?

However it seems like GitHub is distinguishing between private external registries and private GitHub repos: Dependabot version updates: support for private repositories (Cloud Beta) · Issue #155 · github/roadmap · GitHub

About that: Using dependabot with the private github registry isn’t generally working for me. However editing the content of the .npmrc file from:




As described here: Configuring npm for use with GitHub Packages - GitHub Docs

Will at least let dependabot check for the other packages not in the private registry

Bumping @david-guillot’s comment - this does not work yet, which is odd given the blog post is still up.

Some news:

This new feature seems to be related to private registries, which seems to be supported for all languages.

Doesn’t fit my needs (private repositories for Python/pip), but could be useful for some :slight_smile:

I noticed the private registry support feature shipped this week (cool!).

I’d like to know if it’s possible to somehow grant access to allow all private repos within an organization. Currently, it looks like I need to manually select which repos are allowed (from the blog post). With a large number of repos that would benefit from Dependabot, there’s a point at which it becomes burdensome to select them all.

Alternatively, if there’s a way to configure this with Terraform / Pulumi / et al. via the GitHub API, that would be amazing.

The feature is shipped but now I have this issue: Dependabot doesn't see GitHub actions secrets - #32 by ryanhiebert

Same here, it looks like the dependabot secrets are accessible only for dependabot configuration in dependabot.yml. For actions, it is not working :pensive:

I’ve had to read the blog post, docs, and dependabot.yml docs several times because it seems that, and I can’t quite believe it, you once again need to generate Personal Access Tokens to access private repositories and packages. that are all part of the same GitHub organisation?