How do you stop release tags from being moved or deleted on GitHub?

Create a tag ruleset in the repository settings, target your release tag pattern, and select protections that control deleting or renaming tags. Keep the bypass list short. A tag that can be moved quietly lets a release change after people have verified it, which is how trust in a version breaks.

Why tags matter

Consumers pin to versions. If a tag such as a release number can be force moved to a different commit, the same version string points at different code on different days. Build caches, lockfiles and audit notes all assume the tag is stable.

Pinning to a full commit hash is common advice for consumers of actions, because tags can move. Protecting your own release tags is the matching duty on the publishing side.

Create the ruleset

GitHub's ruleset documentation gives these steps.

1. Open the repository and click Settings.
2. Under Code, planning and automation, open Rulesets.
3. Click New ruleset, then New tag ruleset.
4. Name the ruleset.
5. Set enforcement. The default is Disabled, so change it to take effect. Active enforces on creation.
6. Add a bypass list only if you must.
7. Under Target tags, add a target with an fnmatch pattern, for example your release pattern.
8. Under Tag protections, choose the rules, such as controlling who can delete or rename a tag.
9. Click Create.

The page does not list every available tag rule, so read the available rules reference before you decide.

Choosing the pattern

Target the tags that mean something: releases and any tag your pipeline publishes from. Leave scratch tags alone so developers are not blocked from experiments. If you use a prefix convention, a single pattern covers it.

Check that your release automation can still create tags. If the pipeline needs an exception, put the pipeline identity on the bypass list rather than loosening the rule for everyone.

Verify and record

Try to delete a protected test tag with a normal account and confirm it is refused. Note the ruleset in your release runbook. Review the bypass list each quarter, because a long bypass list quietly turns protection into a suggestion.

Where Safeguard fits

Safeguard scans dependencies and builds an SBOM, and its policies and gates can block a pull request that adds a known-vulnerable package. You can try a free scan at gold.safeguard.sh/scan.

Try it yourself

Open the demo and see how a version bump arrives as a reviewable change, which is the flow stable tags support.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Creating rulesets for a repository (GitHub Docs)

Last reviewed: 19 October 2026.