Salt 3006 end of life: planning the move to Salt 3008 LTS
Salt 3006 LTS is down to critical fixes and loses those in June 2027; Salt 3007 STS is already out of active support. A practical, low-risk plan to move masters and minions to Salt 3008 LTS.
The Salt Project publishes a support lifecycle for each release (Salt version support lifecycle). As of October 2026:
| Release | Type | Active support | Critical (CVE) fixes |
|---|---|---|---|
| 3006 | LTS | ended July 2026 | until June 2027 |
| 3007 | STS | ended June 2026 | ended |
| 3008 | LTS | until June 2027 | until June 2028 |
So if your fleet is on 3006, you have until June 2027 before security fixes stop. If it is on 3007, you are already past active support. Either way the destination is Salt 3008 LTS.
What usually goes wrong#
- Repositories. Packages moved from repo.saltproject.io to packages.broadcom.com in late 2024. Old repository files fail with 404s. See installing Salt after repo.saltproject.io.
- Unpinned upgrades. A routine
apt upgradeordnf updatemoves some minions and not others. Pin versions and lock them before you start. - Commercial console plugins. If you run VMware's SaltStack Config / Aria Automation Config / VCF Salt, its master plugin is incompatible with 3008 until patched by hand (KB 448159). Decide that first. See Salt 3008 and SaltStack Config.
- Custom modules and renderers. Python-level changes can break custom execution modules, grains or returners. Test them on a 3008 minion before the fleet.
- Windows minions. The Windows installer is a separate package; make sure your deployment tooling points at the new download location and checks the installer's hash.
A plan that does not wake anyone up at night#
- Freeze versions. Pin and lock the current version on every machine so nothing moves by itself.
- Inventory. List masters, minions per version, OS mix, custom modules, and anything that installs Salt (images, CI, Terraform templates).
- Upgrade the master first. A 3008 master serves 3006 and 3007 minions, so the master can lead.
- Pilot ring. Move a small group of minions that covers each OS you run. Run your usual states in test mode and compare results with the rest of the fleet.
- Waves. Move the rest in rings, inside change windows, checking each wave before the next.
- Update the builders. Change images, first-boot scripts, and CI to install 3008 directly.
- Unpin only deliberately. Keep the lock on 3008 and repeat this process for the next LTS.
How Gardience helps#
Gardience supports Salt 3006, 3007, and 3008 in the same console, so a mixed fleet in the middle of an upgrade is normal, not an error. It groups machines by Salt version (there are built-in groups for each), runs changes in pilot and broad rings inside change windows, and records every machine's result in a tamper-evident audit log. New machines join on the tested version through its pinned, hash-checked installers.
Questions#
Can a Salt 3008 master manage 3006 minions?#
Yes, a newer master serves older minions, which is why the usual order is master first, then minions in waves.
Is it safe to skip 3007 and go straight from 3006 to 3008?#
Yes. 3007 was a short-term release; 3006 LTS to 3008 LTS is the normal path. Test custom modules on 3008 first.
When do I absolutely have to be off 3006?#
Critical fixes for 3006 end in June 2027, per the Salt Project's support lifecycle.
Try Gardience on your own machines
One supported console for Windows and Linux on open-source Salt: patching, a scored STIG/CIS-aligned baseline, drift repair, event-driven automation, two-person approval and a tamper-evident audit log. Flat yearly pricing, not per node.
Free 90-day trial (25 nodes)See it work Compare