🎉 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!

[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.