Get started in shadow mode
Approvegate is one step in your pipeline. Before a production deploy, it checks that the release was approved by someone other than its author, outside a freeze window. New services start in shadow mode, so the check records every verdict but never blocks a deploy until you switch it to Enforcing.
1Create an account and an API key
Start free, then go to Settings → API → API Keys and create a key. Store it as a secret named APPROVEGATE_TOKEN in the repository or organization that runs your deploys.
2Add one step before deploy
In GitHub Actions, add the Approvegate step right before your deploy step. If the check fails, the job stops and the deploy never runs.
jobs:
deploy:
runs-on: ubuntu-latest
environment: production
steps:
- name: Approvegate
uses: ApproveGate/[email protected]
with:
service: ledger-api
environment: production
env:
APPROVEGATE_TOKEN: ${{ secrets.APPROVEGATE_TOKEN }}
# ...your deploy step runs only if the check passesIn GitLab CI or any other CI system, run check.sh from the approvegate-cli repository in the deploy job. It exits non-zero when the deploy isn't approved.
export APPROVEGATE_TOKEN="..." ./check.sh --service ledger-api --release v2.14.3 --environment production
3Let it watch for a week
The first check for a service creates it in shadow mode. Every deploy gets a verdict, allow or would block, with the reason. Shadow mode never fails your pipeline. See the last 7 days of verdicts per service under Settings → Protected Services.
4Flip to Enforcing
When the would-block count looks right, switch the service to Enforcing in Settings → Protected Services. From then on, an unapproved deploy fails the pipeline and says why. Switching back to shadow mode requires a reason, and both changes are written to the audit log.
Action inputs
| Input | Notes |
|---|---|
| service(required) | The service being deployed. Each service + environment pair is gated separately. |
| environment | Deploy environment. Falls back to the job's environment: name when GitHub exposes it. |
| release | Release or version. Derived from a tag push (refs/tags/v2.14.3 → v2.14.3) when possible. |
| branch | Branch being deployed. Derived from a branch push when no release is given. |
| change-request-id | Check one Approvegate change request directly. |
| force-approve | Break-glass override. Always allows the deploy and records it as an override. Needs reason. |
| reason | Recorded with the check. Required with force-approve. |
| on-unreachable | fail (default) blocks if Approvegate can't be reached after retries; allow proceeds, marked unverified. |
Outputs: decision (allow or block), unverified and reason.
Break-glass override and outages
When a hotfix can't wait for approval, force-approve lets the deploy through and records it as an override with the actor, SHA, run URL and reason.
- uses: ApproveGate/[email protected] with: service: ledger-api environment: production force-approve: "true" reason: "SEV1 rollback, incident INC-4821" env: APPROVEGATE_TOKEN: ${{ secrets.APPROVEGATE_TOKEN }}
If Approvegate can't be reached after retries, the step fails closed by default. Set on-unreachable: allow to let deploys proceed during an outage. The step marks them unverified and uploads the details as a job artifact.
Questions?
Email CJ, the founder, at [email protected]. You'll get a reply from a person, usually the same day.
