Installer release readiness
Check signing, release channel, provider validation, and broad-rollout state before assigning an AgentKeeper package to a fleet.
Package signing and fleet readiness are separate decisions. Verify the live release metadata before every pilot, expansion, upgrade, or rollback.
Current release channels
| Platform | Current channel | Broad rollout | Operator action |
|---|---|---|---|
| Windows | Production signed release | Allowed by the release feed | Verify the promoted IntuneWin, signature, hash, and detection rule before assignment. |
| macOS | Signed validation candidate | Not allowed; Jamf, Iru/Kandji, and Intune validation remain pending | Use a limited pilot only. Do not present notarization or stapling as provider certification. |
| Linux | Signed beta | Not allowed | Keep the rollout change-controlled and within the supported RHEL/Rocky versions and architecture. |
Read the machine-readable feeds immediately before deployment:
Interpret the states
- Signed proves the artifact carries the expected publisher signature.
- Notarized and stapled are macOS platform checks; they do not prove that an MDM provider workflow passed end-to-end.
- Provider validated means the documented Jamf, Iru/Kandji, or Intune path completed its release validation.
- Broad rollout allowed is the explicit expansion gate in the release metadata. When it is false, keep assignments to a pilot.
Do not cache this table as release truth. The feeds can advance independently of a documentation deployment.
Pilot gate
Before expanding, verify the package and service, enrollment, policy fetch, loaded hooks, one real allowed action, one controlled pre-execution block, and rollback. Use Validate deployment for the full evidence ladder.
Was this page helpful?