Protection & approvals
What waits for a person before it is deployed, who can approve it, and the settings that decide.
Some changes deserve a second person before they reach an app, even when they arrive through a reviewed pull request. Each app has its own protection settings, on its Deployments page.
What waits
| Change | Waits for an approver |
|---|---|
| Removes something | Always |
| Widens authority | While Approval for authority changes is on |
| Anything else | Never |
Approval for authority changes is on by default. Connecting a repository sets it from the branch: on for an app that deploys the repository's default branch, off for the others (staging, previews). The owner can change it at any time.
A waiting deployment shows in the console's approvals inbox beside agents' and handlers' halts, and the people who can approve it get a "Deployment waiting for approval" email. It expires after 7 days, and a newer deployment of the same app replaces it.
Who can approve
An approver needs the Approve deployments capability, and three more rules hold:
- You approve this plan. The approval is bound to the plan you saw. If the live app changes before the deployment applies, it is planned again; if the plan differs, your approval no longer counts and the deployment waits again.
- You must hold what it grants. A deployment that lets a handler run raw SQL can be approved only
by someone who may give that capability themselves (
SDK_CAP_NOT_GRANTEDotherwise). The same rule applies to a deployment that applies without a person: it is bounded by the member it acts for, which for a push is the member who connected the repository. - Not your own. While Prevent self-approval is on (the default), the person who caused a
deployment cannot approve it (
DEPLOYMENT_SELF_APPROVAL). A push counts as yours when you signed in to Authoric with the same GitHub account that pushed. A one-person team can turn the setting off; every approval made while it is off is recorded as self-approved.
A deploy key never approves anything.
The settings are the owner's
The protection settings, automatic deploys, break-glass editing, deploy keys and the repository
connection are changed only by the app owner, signed in to the console. No key or token can change
them (DEFINITION_OWNER_ONLY).
The record
Every deployment, approval, rejection, rollback, change to these settings, deploy key issued or revoked, break-glass session and drift finding is written to the app's audit log, with who did it, the commit and the plan.