GitHub immutable releases: what gets locked and what does not

An immutable release on GitHub locks its Git tag to one commit and freezes its attached assets, then generates an attestation consumers can check. You can still edit the title, notes and latest status. The tag cannot be moved, and its name cannot be reused. GitHub recommends publishing from a draft.

What is locked

From GitHub's documentation:

• The Git tag is tied to a specific commit. It cannot be moved, and it cannot be deleted while the release exists. If you delete the release, you can delete the tag, but you cannot reuse the name.
• Release assets, such as binaries and archives, cannot be changed or deleted.
• Tags from an immutable release cannot be reused even if the repository is deleted and recreated under the same name.

What stays editable

The release title, release notes, and pre-release or latest status can still change. The documentation does not say whether immutability can be removed after publishing, so plan as though it is permanent.

Why it matters

Several supply chain incidents involved a tag or release asset being swapped after people had begun trusting it. Immutability closes that route for the releases it covers. It does not prove the build was clean, only that what was published has not been altered since.

The attestation

Creating an immutable release automatically generates a cryptographically verifiable record of the tag, commit SHA and assets. A consumer can use it to confirm that the artifact they hold matches what was published. The documentation points to a separate page on how to verify; check the current instructions rather than relying on memory.

The workflow GitHub recommends

1. Create the release as a draft.
2. Attach every asset.
3. Publish.

Once it is published, you cannot fix a missing asset, so finish the draft first. The documentation points to the page on preventing changes to your releases for turning the feature on for a repository or an organization.

What it does not replace

Pin by digest or version where you consume releases, verify provenance where it is offered, and review your own release process. See what Sigstore signing does for a related control.

For consumers, the practical step is to prefer releases that carry this protection when you have a choice, and to record the tag and commit you used in your own build notes. If a dependency later claims a tag was changed, you can compare against what you recorded. For maintainers, the practical step is to test your release process on a pre-release or a throwaway repository first, since a published immutable release cannot be corrected in place.

Quick check

Safeguard can check the components you consume against your policies, which complements publisher side protections like this one.

Sources

• Immutable releases, GitHub Docs

Last reviewed: 19 October 2026.