No. Ansible's documentation says collections follow semantic versioning and that each publish needs a new version, because existing versions cannot be changed. Uploading the same version again returns a conflict error. For a shared collection, that immutability is a feature, and it shapes how you release.
What the Ansible docs state
From the distributing collections guide: collections follow semantic versioning rules, and you increase the major number for incompatible API changes, the minor number for backward compatible new features, and the patch number for backward compatible bug fixes. Duplicate uploads fail with Code: conflict.collection_exists.
You build with ansible-galaxy collection build from the collection's top level directory, which creates a tarball named from the namespace, collection name and version. You publish with ansible-galaxy collection publish, which waits for the import to finish unless you tell it not to wait. A privately hosted Automation Hub accepts only collections its owners authorize, and you must create a namespace there before uploading.
What immutability means for you
If you ship a bad version, you cannot quietly fix it in place. You release a new version and tell callers to move. That is good for trust, since a version that someone reviewed stays what they reviewed. It is also a reminder to review before publishing, because you cannot take back a mistake without a new release.
| Situation | What to do |
|---|---|
| Bug in a published version | Publish a patch version |
| Breaking change needed | Publish a new major version |
| Wrong file included by accident | Publish a new version, and rotate anything sensitive that leaked |
| Same version uploaded twice | Fails with a conflict, bump the version |
Keep sensitive files out of the tarball
The docs describe build_ignore in galaxy.yml: a list of glob style patterns that keep files out of the tarball, such as playbooks/sensitive or *.tar.gz. It works with ansible-galaxy collection build in Ansible 2.10 or newer. Manifest directives are an alternative, but they cannot be combined with build_ignore.
Because published versions cannot be changed, a file included by mistake stays in that version. Check what the tarball contains before you publish it. Listing the archive contents takes seconds.
Release steps for a shared collection
- Merge changes through a reviewed pull request with owners on the roles and plugins.
- Update the version in
galaxy.ymlusing the semver rules above. - Check
build_ignorecovers test fixtures, local inventories and anything sensitive. - Build, then list the tarball contents and read them.
- Publish from a controlled job, not a laptop, with a credential limited to publishing.
- Write release notes with breaking changes first.
Consumers
Callers should pin collections in requirements.yml and verify them. See pinning collections and roles and what galaxy collection verify checks. For signature checks, see signed collections and the keyring.
Where Safeguard fits
Safeguard's SBOM and dependency scanning covers dependencies declared in your repositories, and policies can gate pull requests that change them. It does not scan Ansible playbooks for misconfigurations.
Quick check
How do I fix a bad collection release?
Publish a new version. Existing versions cannot be changed, per the Ansible docs.
Do I need a namespace before publishing to a private hub?
Yes. The docs say you must create a namespace on Automation Hub or a private Automation Hub before uploading.
Sources
Last reviewed: 19 October 2026.
