The ansible-galaxy collection verify command compares the files of an installed collection with the copy on the configured Galaxy server and lists any files that differ. It detects local modification after install. It does not judge whether the collection's code is safe.
What the command does
Once a collection is installed, the verify command checks that its content matches the collection on the server. It expects the collection to be in one of your configured collection paths and to exist on one of your configured servers. When all is well the output is quiet. When something changed, the altered files are listed under the collection name, for example a modified module or inventory plugin.
Add -vvv for more detail, such as the installed path, the remote URL used for the check and a message that checksums match.
Details that trip people up
- If you have a pre-release or non-latest version installed, name the version, for example
my_namespace.my_collection:1.0.0. If you omit it, the installed copy is compared against the latest on the server. - You can give a
requirements.ymlfile instead of names, but dependencies listed in that file are not included and must be verified separately. - Verifying against tar.gz files is not supported. If your requirements file has tar paths or URLs, the
--ignore-errorsflag lets the rest be processed.
What it proves and what it does not
| Question | Answer from verify |
|---|---|
| Did someone edit the installed files? | Yes, it lists modified files |
| Is the server copy trustworthy? | No, it trusts the server copy as the reference |
| Does the collection contain flaws? | No |
| Was it signed by a key you trust? | Only with signature options and a keyring |
The last row leads to signed collections, covered in a separate post on signature verification.
Where to run it
- After installing collections in a build or on a control node, as a step in the job.
- On a schedule on long lived control nodes, since those can be altered.
- Before a release run, if collections live on a shared automation host.
A simple loop in CI is enough: install from a pinned requirements file, then verify each name and version.
Why this matters
Your control node runs modules with the privileges of your automation accounts. A changed plugin on that node can touch every host you manage. A cheap check that installed content still matches the source closes one easy gap.
Try it yourself
Click through it at your own pace, or open it full screen. Click a dependency to see its version and source, the same facts you want to compare when you verify a collection.
Quick check
Is the output noisy on success?
No. The command is quiet if verification succeeds, unless you add -vvv.
Does verify check roles?
The documentation covers collections. Treat roles separately and pin them.
Can I verify offline?
With signed collections and the offline option, yes, using signatures saved at install time.
Safeguard offers SBOM and dependency scanning and policy gates that can block a pull request on findings, and you can try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
