Choose hosted if nobody on your team wants to patch, back up and monitor another server. Choose self-hosted if you need the mirror inside your own network or under your own data rules and you can name the person who owns it. Either way, the mirror is a security system, so assign an owner first.
What changes between the two
A mirror sits between every build and the public registry. Whoever runs it can see what you install and, in the worst case, change what you receive. That is why the choice is mostly about who you trust to run it and who you can staff.
| Question | Hosted | Self-hosted |
|---|---|---|
| Who patches the software? | The provider | You |
| Who holds the cache and logs? | The provider, under its terms | You |
| Network position | Reached over the internet or a private link | Inside your network |
| Failure handling | Provider's availability | Your own backups and restarts |
| Access control | Provider's identity options | Whatever you integrate |
Five questions to answer
- Who is the named owner, and who covers when they are away? A mirror without an owner decays.
- Can you patch within days when the mirror software itself has an advisory? Server software gets security advisories like any other software, so expect to patch.
- Do your customers or contracts restrict where build data and logs may live? Ask legal or your customer contact, since this is not something to guess.
- What happens to builds if the mirror is down? Decide fallback behavior before the first outage.
- Can the mirror authenticate people through the identity system you already use, so offboarding works?
A simple scoring approach
Give each question a score of one to three for each option, based on your honest capacity, not the vendor's brochure. If self-hosted wins only because it feels cheaper, check whether you have counted patching, backups, monitoring and on-call time. Those costs are real even when there is no invoice.
Start small
You do not need to decide for ever. A pull-through cache for the one or two ecosystems you use most covers most of the risk reduction. Add ecosystems as needed. Write down the exit path too: how you would point clients back at upstream or at another mirror, which for most clients is a config change.
What either choice does not do
A mirror does not decide which packages are safe. It controls where they come from. You still need rules for new packages, a review of updates and scanning of what you install. Pair the mirror with dependency scanning and a policy for what may enter.
Where Safeguard fits
Safeguard's SBOM and dependency scanning and policy gates work on what your projects resolve, whichever mirror served it. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is a hosted mirror automatically more secure?
Not automatically. You trade your patching burden for trust in the provider. Evaluate both.
Do we need a mirror at all with five developers?
Not always. Lockfiles, hash checks and scanning come first. Add a mirror when you want control, caching or an audit trail.
Last reviewed: 19 October 2026.
