Comparison
Release Passport vs Argo Rollouts and Flagger
Argo Rollouts and Flagger manage progressive delivery and traffic shifts. Release Passport decides whether a release should start, continue as canary, hold for missing evidence, or recommend rollback based on policy and runtime facts.
Argo Rollouts / Flagger
What the existing tool should keep doing.
It does not shift traffic or manage Kubernetes rollout objects.
It does not replace analysis templates, metric providers, or rollback commands.
It does not claim a canary eliminates production risk.
Release Passport
What Release Passport adds.
Pre-rollout evidence checks across artifact provenance, GitOps sync, runtime health, and rollback readiness.
A durable release-level decision record independent of any single rollout controller.
Customer-scoped connectors instead of broad cluster scans.
Clear operator reasons when a rollout should hold or roll back.
How to use them together.
Let Argo Rollouts or Flagger control traffic, analysis runs, and rollback mechanics.
Run Release Passport before the rollout starts and during watch windows when policy requires it.
Feed rollout status, analysis results, previous revision, metrics, and incident state into the passport.
Use ALLOW_WITH_CANARY when policy permits progressive rollout with explicit watch constraints.
Recommended release flow.
- 1CI renders manifests and records source SHA plus image digest.
- 2Release Passport checks readiness and returns ALLOW, ALLOW_WITH_CANARY, REQUIRE_APPROVAL, HOLD, BLOCK, or ROLLBACK_RECOMMENDED according to policy.
- 3Argo Rollouts or Flagger executes traffic progression.
- 4A follow-up gate records watch-window evidence and rollback recommendation if signals degrade.
Boundary check.
Customer installs run the self-hosted console, API, worker, CLI gate path, scoped connectors, RBAC, audit log, retention controls, signed artifacts, and provenance checks. Owner checkout, payment, license issuance, and package entitlement administration stay outside the customer runtime.