Comparison
Release Passport vs LaunchDarkly guarded rollout
LaunchDarkly can guard feature exposure and feature rollout. Release Passport keeps the release-level decision self-hosted, signed, and tied to deploy evidence, while feature-flag state can be included as scoped evidence.
LaunchDarkly guarded rollout
What the existing tool should keep doing.
It does not evaluate flag rules or replace the feature management system.
It does not manage experimentation, targeting, or SDK behavior.
It does not make a passing release risk-free.
Release Passport
What Release Passport adds.
A deployment-level audit decision that links flags to source SHA, image digest, rollout, and policy.
Evidence from runtime health, rollback readiness, incidents, GitOps, CI, and manual approvals.
Customer-controlled RBAC, audit log, data retention, and sanitized reports.
No owner checkout, payment, license issuance, or entitlement admin code in customer runtime.
How to use them together.
Use LaunchDarkly for flag targeting, progressive exposure, and feature-level kill switches.
Feed relevant flag state, rollout percentage, and guardrail results into the release passport.
Run Release Passport before deployment promotion and during post-deploy watch windows.
Keep customer release evidence in the self-hosted runtime with customer-owned retention policy.
Recommended release flow.
- 1Pipeline records release identity and deploy artifact.
- 2Feature-flag state is attached as scoped evidence when relevant.
- 3Release Passport evaluates deploy readiness and policy.
- 4LaunchDarkly controls exposure while the passport records the release decision and watch evidence.
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.