When would pinned be used in labels?

[wsw70]

I am reading through the documentation and trying to imagine a use case for sentinel.policy: pinned.

Images can be "naked", or with a non-semver tag, or with a semver tag.
In the first two cases there not really a "preferred" version; by using them one is expecting the version to change.
In the last one, it is already pinned, either to a specific, immutable tag; or one wants to update within the constraints of the version.

What would be a case where pinned is used?

[Will-Luck]

Good question. pinned doesn't mean "this image uses a specific version tag" - it means "Sentinel should completely ignore this container". When a container's policy is pinned, the scanner skips it entirely: no registry check, no digest comparison, no update queue entry, nothing.

Some real-world use cases:

• Containers you manage through other tooling - if you deploy something via CI/CD or Ansible and don't want Sentinel touching it at all
• Known-fragile services - something where any unexpected restart would be disruptive (e.g. a database container you'd rather update manually during a maintenance window, outside of Sentinel)
• Dev/test containers - local builds or custom images where checking a registry would just produce errors
• Temporary opt-out - you can set pinned via the dashboard to pause updates for a specific container without changing your compose file, then switch it back to manual or auto later

It's basically a per-container "don't touch this" switch. The label version (sentinel.policy: pinned) bakes it into the compose file so it persists across docker compose up -d, while the dashboard override is stored in Sentinel's database.

[wsw70]

All clear, thanks!