Blog · 2026-10-19 · Gardience Engineering

repo.saltproject.io is gone: install and pin Salt in 2026

Salt install failing with 404s from repo.saltproject.io or bootstrap.saltproject.io? The packages moved to packages.broadcom.com in late 2024. How to fix installs, pin versions, and stop it biting again.

If a Salt install or upgrade suddenly fails with 404 errors, the cause is almost always an old repository address. In October 2024 the Salt Project moved its packages off its own hosting to integrate with Broadcom's infrastructure (migration notice):

• repo.saltproject.io and archive.repo.saltproject.io stopped serving packages.
• Packages now live on Broadcom's Artifactory at packages.broadcom.com (saltproject-deb, saltproject-rpm, and a generic area for Windows and macOS).
• Everything older than Salt 3006 was dropped. 3005, 3004, and earlier are no longer downloadable from the project.
• The bootstrap script moved to GitHub Releases; the old bootstrap.saltproject.io and winbootstrap.saltproject.io addresses were retired.

Anything that still points at the old hosts breaks: apt and yum repository files, golden images, CI jobs, Ansible roles and Terraform templates that install the minion.

Fix it on Debian and Ubuntu#

1. Remove the old source and key (/etc/apt/sources.list.d/salt.list and the old keyring).
2. Download the current signing key from packages.broadcom.com and check its SHA-256 against a value you recorded when you first trusted it.
3. Add a source pointing at https://packages.broadcom.com/artifactory/saltproject-deb/.
4. apt-get update, then install the exact version you want, for example salt-minion=3008.3.

Follow the official install guide for the current paths.

Fix it on RHEL, Rocky, Oracle Linux, and Amazon Linux#

Replace the old .repo file with one pointing at saltproject-rpm on packages.broadcom.com, import the current key, and install the version you want.

Fix it in the bootstrap script#

Download bootstrap-salt.sh from the salt-bootstrap GitHub releases and pin it to one release. Do not pipe an unpinned script from the internet into a shell on production machines: record the release, check its SHA-256, then run it with an explicit Salt version (-X stable 3008.3).

Pin your version, every time#

The migration notice warned of "disruptive changes ... around installing, upgrading, and pinning/locking Salt". Two habits prevent most of the pain:

• Install an exact version, never "latest".
• Lock it so routine OS updates do not move it: apt-mark hold salt-minion salt-common on Debian and Ubuntu, dnf versionlock add 'salt*' on RHEL family systems.

Upgrade Salt deliberately, a few machines first, when you choose to.

A second source#

We now run a free, verified mirror of the Salt packages with the same layout as Broadcom's, so a hosting change never breaks your installs again: see mirror.gardience.com.

How Gardience handles it#

Gardience pins and checks every agent installer it uses. Its enrollment playbook and first-boot scripts download a pinned bootstrap release and check its SHA-256 before running it (and the Windows MSI likewise), install one tested Salt version, and lock it. On end-of-life Debian releases the bootstrap script refuses, Gardience installs from Salt's own repository with a pinned signing key. Moving a fleet to a new Salt version is a tested Gardience release, not a surprise in a nightly update.

Questions#

Where can I download Salt 3005 or older now?#

Not from the Salt Project: the migration dropped every package older than 3006. If you still run 3005 or older, plan the move to Salt 3008 LTS.

Why did my CI pipeline start failing?#

Most likely it installs Salt from repo.saltproject.io or runs the bootstrap script from bootstrap.saltproject.io. Point it at packages.broadcom.com or a pinned GitHub release of salt-bootstrap.

Which Salt version should new machines get?#

Salt 3008 LTS: it has active support to June 2027 and critical fixes to June 2028, per the Salt Project's support lifecycle.