Approval rules require manual approval from authorized users before a
deployment can proceed. This adds a human checkpoint to your deployment pipeline
for high-risk changes.
Overview
Why Use Approval Rules?
Approval rules help you:
- Add human oversight - Require sign-off for production deployments
- Enforce compliance - Meet regulatory requirements for change management
- Coordinate releases - Ensure stakeholders are aware before deployment
- Reduce risk - Catch issues that automated checks might miss
Configuration
Properties
Minimum number of approvals required before the deployment can proceed.
Grandfathering
Versions that were created before an approval rule was added to a policy are
automatically allowed through (grandfathered in). This prevents newly added
approval rules from blocking already-in-flight releases.
Common Patterns
Single Approval for Production
Basic approval gate for production deployments:
Multiple Approvals for Critical Services
Require multiple sign-offs for high-risk deployments:
Approval with Gradual Rollout
Approve once, then roll out gradually:
Approval Workflow
1. Release Created
When a new release is created that matches an approval policy, it enters an
“awaiting approval” state.
2. Approval Requested
Users with appropriate permissions can view pending approvals in the Ctrlplane
UI or via API.
3. Approval Granted
Authorized users approve (or reject) the release. Each approval is recorded with
the user and timestamp.
4. Deployment Proceeds
Once the required number of approvals is met, the deployment continues through
any remaining policy rules.
Best Practices
Environment-Based Approvals
Recommendations
- ✅ Require approvals for production environments
- ✅ Use multiple approvals for critical services
- ✅ Combine with verification for defense in depth
- ✅ Document approval requirements in runbooks
- ✅ Set up notifications for pending approvals
Next Steps