Choose hosted when your registries are public, your repositories live on one supported platform, and you want little to operate. Choose self-run when you need private network access, control of run frequency, or credentials that must not leave your infrastructure. Many teams start hosted and move specific repositories to self-run.
What actually differs
The difference is who runs the job and where. A hosted tool runs on the vendor's or the code host's infrastructure. A self-run tool runs on your runners, on your schedule, with your network.
Several documented behaviors follow from that:
- Run frequency. The documentation of one bot says that how often it runs is set by its administrator, and a repository's own schedule can only narrow it. For the hosted app, the vendor decides when it runs. With a self-run command line tool, it runs once and exits, so it runs as often as you schedule it.
- Network reach. The documentation of another bot says that to reach registries on private networks you configure it to run on self-hosted runners. Hosted jobs can connect only to hosts on an egress allowlist.
- Credentials. A self-run tool reads credentials from your own secret management. A hosted one stores them in its own secret store, which you must trust and rotate.
- Platform credentials. The first bot notes that by default it holds just the credentials for the code platform, and anything else, including private registries and other hosts, must be provisioned.
A decision table
| Need | Leans to |
|---|---|
| Public registries only, one platform | Hosted |
| Registries inside a private network | Self-run |
| Strict rules on where credentials live | Self-run |
| Control of exact run times and rate | Self-run |
| No spare engineer time | Hosted |
| Many platforms or custom managers | Self-run |
| Quick pilot | Hosted |
Hidden costs
Self-run is not free. You maintain the runner, upgrade the tool, watch its logs and handle its failures. A silent failure of a self-run job looks like a quiet week, so you need a heartbeat check. The documentation of the first bot also notes that run time grows with the number of repositories and pending updates, so large estates need capacity planning.
Hosted has costs of its own: less control over timing, limits on network reach, and dependence on the vendor's roadmap for ecosystem support.
Security questions for either choice
- Where does the job run, and who can access the runner?
- What credentials does it hold, and are they read-only?
- Can it execute manifest code or install scripts? See our post on update tools that run project code.
- How are tool upgrades and its own dependencies kept current?
- What does it log, and where?
A staged path
Start with a hosted pilot on three repositories. Record what works and what breaks, especially private registry access and lockfile updates. If private network access or credential rules block you, move those repositories to self-run and keep the rest hosted. Having two modes is fine if you keep one configuration standard, such as shared presets, in a single place.
Quick check
Can I mix hosted and self-run tools?
Yes, but avoid running two tools on the same repository, because they will open duplicate pull requests.
Does self-run mean more secure?
Not automatically. It gives you control over where credentials live and what the job can reach, but you also own its hardening.
Safeguard can sit next to either choice. It builds an SBOM from manifests and lockfiles, applies policies and gates to changes, and uses reachability analysis to show which flagged dependencies your code calls. Fix pull requests are off by default, with every category on Manual. A free scan is available.
Sources
- Update bot documentation: scheduling and running
- Update bot documentation: private package support
- Code host documentation: private registries for the update bot
Last reviewed: 19 October 2026.
