Alpine's release branches page lists the 3.21 branch with end of support on 1 November 2026, only the main repository covered, and 3.20 already past its date. If your images use alpine:3.21 or older, find them now and move to 3.22 or newer before that date.
What the Alpine page states
Alpine makes a release branch each May and November. The page says the main repository is typically supported for two years, and the community repository is supported until the next stable release. Security fixes beyond that can be made on request when patches exist.
Here is the part of the table that matters today.
| Branch | Branch date | End of support | Support level |
|---|---|---|---|
| v3.20 | 2024-05-22 | 2026-04-01 | on request |
| v3.21 | 2024-12-05 | 2026-11-01 | main |
| v3.22 | 2025-05-30 | 2027-05-01 | main |
| v3.23 | 2025-12-03 | 2027-11-01 | main |
| v3.24 | 2026-06-09 | 2028-06-01 | main and community |
Two things follow. A 3.20 image is already outside normal support. A 3.21 image has about two weeks left, and it already lacks community repository coverage.
Why the community repository matters
Many images install tools from the community repository. If a package you rely on lives there, support for it on 3.21 stopped when the next stable branch arrived. Check which repository each of your installed packages comes from before you decide the urgency.
How to find affected images
- Search Dockerfiles for
alpine:3.21,alpine:3.20, and older tags. Language images with an alpine suffix also embed a branch, so read their tag details. - Scan running images, not only Dockerfiles. Some images were built from files nobody remembers.
- In a scan or SBOM, the operating system name and version are recorded. Filter on them to get a list across services.
How to move
Change the tag to a supported branch, rebuild, and run your tests. Alpine uses musl libc and busybox, so a program that behaves differently on another libc is worth a second look when branches change. Most services move without drama, but test the ones with native extensions or compiled binaries first.
Pin the result by digest if you want repeatable builds, and keep the rebuild schedule going so that the new base keeps receiving fixes.
What if you cannot move by 1 November
Write an exception: the image, the reason, the owner, and a date. Add whatever limits exposure, such as removing public access or running with a read only filesystem. An exception with an end date is a plan. One without is a leftover.
Where Safeguard fits
Safeguard's SBOM and container scanning record the base operating system for each image, so a query for every image on a given Alpine branch is one search. You can try the free scan at https://gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how the scan reports the base operating system, since that is what you filter on to find Alpine branches.
Quick check
Is an image on an unsupported Alpine branch vulnerable?
Not by itself. It means the branch will no longer get routine fixes, so any new issue may go unpatched. Scan the image to see what is present today.
Does a newer tag like alpine:3 fix this?
A moving tag follows a newer branch only when you rebuild and pull. Check what the tag resolves to now and rebuild so your image actually changes.
Sources
Last reviewed: 19 October 2026.
