Sometimes, but not by default. A fallback to the public registry keeps builds moving, yet it also skips the rules your mirror enforces. Allow it only for public packages pinned by a lockfile, never for private names, and make every fallback visible with an alert so someone reviews it.
What a fallback gives up
Your mirror is more than a speed layer. It may block a version after an incident, hold a delay on brand new releases, or serve only approved packages. When CI quietly reaches around it, all of those controls disappear for that build. The build still passes, and nobody notices.
Different tools behave differently, which is why "just configure a fallback" is not one setting:
- Go's default GOPROXY value is the public module proxy followed by direct, so the go command tries the proxy and then goes straight to version control if the proxy lacks the module. The Go reference describes this, and also lets you set the value to off to disallow downloads from any source.
- pip looks in the index, local directories and any extra repositories you list. The pip documentation describes extra index URLs as additional places to search, which is the mechanism behind many confusion incidents. See pip extra index URL and internal mirrors.
- Maven picks one mirror per repository and does not aggregate several. More on that in can Maven fail over to a second mirror.
Decision guide
| Situation | Fall back? | Why |
|---|---|---|
| Public package, version pinned in a lockfile with a recorded hash | Often yes | The bytes are checked against what you already approved |
| Public package, new version not yet in your mirror | No | This is the case your intake rules exist for |
| Private or internal package name | Never | A public lookup for a private name invites a malicious upload |
| Release hotfix with an incident open | Yes, with a named approver | Speed matters, and a person owns the risk |
| Nightly or scheduled job | No | It can wait for the mirror to return |
How to make a fallback safe enough
- Fall back at the job level, not silently inside the tool. A separate, clearly named pipeline variant is easier to audit than a hidden second URL in a config file.
- Keep private scopes and namespaces bound to your own registry so they cannot resolve publicly. The pattern is in npmrc scoped registry and token scoping.
- Install strictly from the lockfile. The frozen install flags are compared in frozen lockfile flags.
- Emit an alert or a ticket every time the fallback runs, with the list of packages that came from the public side.
- After the mirror recovers, compare the build's package list against the mirror and investigate anything that differs.
When no fallback is the right answer
If your mirror holds a curated set or enforces a release delay, a fallback may undo the very policy you built. In that case, plan for the mirror to be reliable instead: run it in more than one location, keep the last known good cache, and rehearse recovery. Read vendoring vs cache vs mirror for the trade-offs, and minimum release age policies for what a fallback can bypass.
Where Safeguard fits
A fallback build is the build you most need an inventory for. Safeguard's SBOM and dependency scanning, with policies and gates, lets you flag a build whose packages did not come from the expected source and block merges that fail your rules.
Quick check
Is a fallback ever safe for private packages?
No. A public lookup for a private name is the setup for dependency confusion. Keep private names bound to your own registry.
Can a lockfile make fallback safe on its own?
It helps a lot for packages you already approved, because versions are fixed. It does not help for a version you have never reviewed.
Sources
Last reviewed: 19 October 2026.
