Give the update tool a dedicated read-only credential for each private registry, declare each registry host in its configuration, and store the secret in the tool's own secret store. Never reuse a deploy or publish token. Then confirm the tool can reach the registry over the network.
Why private registries need explicit setup
A public registry needs no login. A private one does, and an update tool must authenticate at several points. The documentation of one self-hostable bot lists four: loading private configuration presets, looking up new versions, looking up changelogs, and passing credentials to package managers when it regenerates lockfiles and checksums.
That last point surprises people. The tool may find a new version without trouble and still fail while rewriting the lockfile, because the package manager it runs does not understand the tool's credential format. The tool has to translate its stored credentials into environment variables or config files for each manager. When that translation is missing, the pull request is created without the lockfile change, or not created at all.
What the documentation of a hosted bot adds
Another major bot's documentation says a registry must be declared in its configuration file to be reachable at all, even if it allows anonymous access. Update jobs can connect only to hosts on an egress allowlist, and a host defined only in an ecosystem file such as an npm config file is not added to that list.
It also notes that organization level registries can use a token, a username and password, or OIDC, and that for private network registries you run the bot on self-hosted runners. Where it supports it, registry credentials can be bound to a package scope.
Setup steps
- List every private registry your repositories use, by ecosystem. Include container registries and Git hosts.
- Create one read-only credential per registry, ideally per team or per scope. The tool only needs to pull.
- Declare each registry host in the tool's configuration and store the secret in the tool's store, not in the repository.
- Prefer short-lived or federated credentials over long-lived tokens where the tool supports them.
- Run one update cycle and read the logs for authentication errors, especially on lockfile steps.
- Set a rotation date and an owner for each credential.
Checks that catch real problems
| Check | What to look for |
|---|---|
| Reachability | Can the tool's runner reach a registry inside a private network? |
| Scope | Does the credential read only the packages the repository needs? |
| Fallback | Does the tool silently use a public registry for an internal package name? |
| Lockfile step | Does the pull request include the regenerated lockfile? |
The fallback row is a supply chain concern. If an internal package name also exists on a public registry, a misconfigured tool may resolve the public one. Some tools let you mark a private registry as the replacement for the default base URL, which closes that gap. Check your tool for an equivalent.
Do not forget the pull request side
Builds on update pull requests need registry credentials too, and those may be restricted by default. See our post on update bot pull requests and CI secrets for how to give builds read-only access without exposing everything else.
Quick check
Does an update tool need credentials just to check for new versions?
Yes for private packages. It must authenticate to look up versions, changelogs, and, in some tools, when updating lockfiles.
Can I reuse my CI publish token?
You should not. Update tools only need to read, so create a separate read-only credential.
Safeguard reads your manifests and lockfiles into an SBOM and flags vulnerable dependencies, so you can see which private and public packages you depend on. Reachability analysis shows which flagged ones your code calls. A free scan works on public repositories.
Sources
- Update bot documentation: private package support
- Code host documentation: configuring private registries for the update bot
Last reviewed: 19 October 2026.
