Whether a collection release is live is not visible from the cluster or the gist. A release can be pinned in the fleet repo and deployed with arc.yml while a host's Compose project stays at an older version: on 2026-10-04 the docker-prune service had been merged and released for hours and was installed on no host, because arc.yml does not touch the hosts and nobody ran site.yml.
An idea: each role stamps the collection version it last applied, the arc role into a ConfigMap the heartbeat publishes in fleet-health.json, and the cluster role per host (for example as a node annotation set from the host that waits for the nodes). A host whose stamp is behind the pinned version then shows as drift in the gist. Open questions: the cluster role runs before the API exists on a first bootstrap, so the stamp can only be written once the node is up, and the stamp records what was applied, not what is actually running, so it can still be wrong after a manual change.
Deferred because unattended deploys would make a better answer: with a 1Password service account the fleet could run site.yml --check --diff on a schedule (zero changes means deployed) and apply on merge. That is a secrets decision for the owner, and until it is made the fleet is deployed by hand.
Revisit trigger: the next time a release is found pinned but not fully deployed, or when the owner decides on unattended deploys.
Whether a collection release is live is not visible from the cluster or the gist. A release can be pinned in the fleet repo and deployed with arc.yml while a host's Compose project stays at an older version: on 2026-10-04 the docker-prune service had been merged and released for hours and was installed on no host, because arc.yml does not touch the hosts and nobody ran site.yml.
An idea: each role stamps the collection version it last applied, the arc role into a ConfigMap the heartbeat publishes in fleet-health.json, and the cluster role per host (for example as a node annotation set from the host that waits for the nodes). A host whose stamp is behind the pinned version then shows as drift in the gist. Open questions: the cluster role runs before the API exists on a first bootstrap, so the stamp can only be written once the node is up, and the stamp records what was applied, not what is actually running, so it can still be wrong after a manual change.
Deferred because unattended deploys would make a better answer: with a 1Password service account the fleet could run site.yml --check --diff on a schedule (zero changes means deployed) and apply on merge. That is a secrets decision for the owner, and until it is made the fleet is deployed by hand.
Revisit trigger: the next time a release is found pinned but not fully deployed, or when the owner decides on unattended deploys.