🎉 Immutable Releases: Public Preview is Here!

[tinaheidinger]

We’re excited to announce that Immutable Releases are now available in public preview and will be gradually rolled out to all organizations and repositories!

Immutable Releases add a new layer of supply chain security to GitHub Releases by preventing changes to release assets and their associated tags after publication. This helps ensure that the software you publish (and your users consume) remains secure and trustworthy. With Immutable Releases, release assets can no longer be added, modified, or deleted after publishing, and tags are protected from being moved or deleted.

We’d love for you to try out Immutable Releases and share your feedback! Your input will help us polish the experience as we work toward general availability.

• 📢 Read the changelog post
• 📚 Check out the documentation

Let us know your questions, thoughts, and feedback in the discussion below. Thanks for helping us make GitHub Releases even more secure and reliable for everyone!

[pleasedontddosme]

Sounds great. Huge work guys! Much love to the GitHub team, especially the great devs!

[KaloudasDev]

Hi @tinaheidinger,

This is a fantastic addition! Immutable Releases will greatly enhance the security and trustworthiness of software delivery by ensuring release artifacts remain exactly as published. This kind of supply chain protection is critical, especially as software supply chain attacks continue to rise.

I’m excited to test this feature and provide feedback as it rolls out. Kudos to the team for prioritizing security and improving the release workflow.

Thanks for sharing and looking forward to seeing Immutable Releases become generally available!

Best,
KaloudasDev

[AdnaneKhan]

Will there be an API to manage this at the repository level?

Additionally, how does this work with uploading release assets?

The docs are clear that assets can't be altered, but what about adding new ones?

Is there a certain window where release assets must be added after creating an immutable release or can devs add assets to an immutable release in perpetuity.

So you can't add/remove assets after creating an immutable release. So I might ask - how exactly does this work with publication workflows where there is a delta between release creation via API and asset addition (as they are different API calls).

I just tested with a really simple workflow: https://github.com/AdnaneKhan/TestImmutable/actions/runs/17275237419/job/49030192026#step:5:17

Does this mean that projects that use Actions to create releases and attach assets need to make sure that the workflow:

• First creates a draft release
• Adds release assets
• Publishes the draft

GitHub should add a warning about this interaction as this will lead to a lot of projects release workflows failing to upload assets if they enable the feature and their CI doesn't create a draft first.

[bdehamer]

Will there be an API to manage this at the repository level?

Yes, we haven't yet published the APIs, but there will be endpoints for enabling/disabling immutable releases at the repository level as well as enforcing this setting at the org level.

So you can't add/remove assets after creating an immutable release

Correct. As you noted, the recommended workflow for publishing an immutable release will be to initially create the release as a draft, attach any associated assets, and then publish the draft.

We'll be sure to make this clear in the documentation. Thanks!

[woodruffw]

Hi @bdehamer (good to see you here!)

I did a quick scan through the docs again, but couldn't find a reference to the drafting behavior. Do you know if those docs changes are still planned?

(This caused some confusion on one of my projects, and I want to make sure I can rely on drafts being mutable before rolling out immutability on releases again!)

xref zizmorcore/zizmor#1165 (comment)

[hfhbd]

After enabling immutable releases, I am still able to delete the release and the tag later.

[AdnaneKhan]

I tested that and it doesn’t allow you to.

Let’s say I make an immutable release for tag v1.0.1. Then I go and delete the release and the tag.

Now, due to the rules GitHub applies under the hood with immutable releases, if I try to create v1.0.1 it will block me.

[haya14busa]

Thanks @AdnaneKhan for confirming it.
That's awesome 💯

[andreaso]

On the topic of GitHub Actions...

Should be noted that even it's impossible to recreate that deleted v1.0.1 release tag that won't stop someone from instead replacing it with a v1.0.1 branch, which equally well with satisfy uses: org/[email protected].

Hence, if we are going to trust immutable releases in a GitHub Actions context it feels like we'll need to verify release attestation on each run?

[hfhbd]

@andreaso Regarding Github Actions: according to the roadmap, immutable actions will finally available this month: github/roadmap#1103 🎉 If you not want/able to use immutable actions, use the full commit hash. You can/should even enforce it: https://github.blog/changelog/2025-08-15-github-actions-policy-now-supports-blocking-and-sha-pinning-actions/

[haya14busa]

that won't stop someone from instead replacing it with a v1.0.1 branch, which equally well with satisfy uses: org/[email protected].

Oh, that's good point.
It would be great if GitHub also blocks branch with the same immutable tag name.

[VictorMoni]

Awesome, nice work! 😺🖖❤️

[suzuki-shunsuke]

Thank you for the great feature!
I have a feature request.
It would be great if we can enable this feature in all repositories of users by user settings same as organizations.
If users have a lot of repositories, it's hard to enable this feature by repository.

[audunsolemdal]

In general I think this is a good setting, however I would like it to be more flexible.
To be concrete, I would like to ignore the immutable release enforcement for some specific patterns.

https://github.com/miljodir/workflow-templates/tags

If for instance the tag ends with /v1 or /v2 it should be mutable. Other tags e.g. 1.0.0 and 1.0.1 should be immutable

[suzuki-shunsuke]

In my understanding, tags are mutable unless you create releases associated with those tags.
I'm not sure your usecases, but you can create immutable releases for tags x.y.z while keeping tags /v1 or /v2 mutable.

[audunsolemdal]

I just tested this and it seems that you are correct in that tags without a release are still mutable.

[tinaheidinger]

That's correct - plain git tags aren't affected by this setting, it is scoped to releases and their associated tags

[audunsolemdal]

Just scanned through my org. Only a single repo out of 300+ repos, where 35 of them use releases, only one of the repos has a mutable Github release.
Ideally I want to activate the immutable releases setting at the org level with "all repositories" with the possibility of adding exclusions.

I know it is possible to use "selected repositories", but the UX for this is bad if needing to select hundreds of repositories, and won't auto add new repositories when created. As minimum there should be a "select all" button in the "select repositories" context before I unselect specific repos so I don't have to click through hundreds of repos.

Would you consider improving the flexibility for repository targeting to be similar to repository rulesets? For instance including and excluding by repository name patterns and/or repository properties:

[louwers]

Noticed a small bug.

Description

I am pushing a new tag to a repository.

And I get

Repository rule violations found for refs/tags/android-v11.13.4.

When I click the "Review all repository rules at ..." link, I see that no repository rules exist for this repository.

This happens because an immutable release that has since been deleted existed for that tag. The error message is wrong.

Reproduction Steps

1. Create an immutable release
2. Delete the immutable release
3. Try to push a tag with the same as the previous immutable release

It will fail with the (wrong) error message.

Expected behavior

The error message should read:

Cannot create tag android-v11.13.4 due to a previous immutable release with this tag.

Or similar.

[juhoinkinen]

I see this wrong error message too.