Approvegate is a change management solution that checks your deploy against a signed approval record and documentation before it reaches production — and blocks it, with a reason, if it isn't real.
# deploy stage
deploy_ledger-api_prod:
stage: deploy
environment:
name: production
script:
- approvegate check
--service ledger-api
# SHA + release read automatically —
# release comes from the tag when the pipeline
# runs off a tag push, e.g. v2.14.3.
# branch-triggered deploys need --release explicitly.
# fails the job if not approvedv2.14.3 has not been approved for prod deployment. Active approved deployment tickets - www.approvegate.io/team/approvegate/active
exit 1 · pipeline stopped before promotion
Branch protection checks that a diff was reviewed before merge. It says nothing about whether this build is cleared to ship to production right now — under the current policy, outside any freeze. Approvegate is that second check.
"The PR was reviewed and merged. Three weeks later that build sat in the queue, ready to ship — and nobody had re-authorized the deploy."
Approvegate isn't a portal you migrate into. It's an API your pipeline calls, backed by a minimal record of who approved what.
A GitHub Action or GitLab CI step you drop into your existing deploy job. It calls the Approvegate API with the artifact version and service name — and the pipeline fails closed if the answer is no.
Just enough surface to create a change request bound to an artifact, record who approved it, and attach the policy that governed it. Not a release planner. Not a second Jira.
You won't know the exact build yet — the pipeline hasn't run. Approve the release and who's allowed to sign off; the artifact locks in automatically the moment it's built. Set an expiry, and a stale approval can't authorize a deploy weeks later without anyone remembering to revoke it.
This is the same control that would have caught the three-week-old build from earlier — an expired approval can't authorize a deploy, whether anyone remembers to check or not.
The check calls out to us on every deploy, so availability matters — we build and monitor toward 99.99% uptime. But an SLA alone isn't good enough for a P1. You configure your own emergency path, in your own pipeline, on your own terms.
deploy_ledger-api_prod_emergency:
stage: deploy
environment:
name: production
script:
- approvegate check
--service ledger-api
--release v2.14.4-hotfix
--force-approve
--reason "sev1-incident-4821"
# bypasses the standard check, logged as an emergency deployDeclare a time-boxed exception instead of editing the pipeline under pressure. No file to commit, no flag to remember to remove — it reverts to your normal policy on its own.
This isn't here to convince you that change approval matters. It's for teams that already believe that, already have a process, and are tired of it being paperwork instead of protection.
Every check — allow, block, or escalation — lands in an append-only log: artifact, approver, policy, and result. Export it when an assessor asks. You didn't do anything extra to get it.
See a sample exportA small number of design partners get the package installed on one pipeline, one production service — running against a real deploy in prod or non-prod.
Drop the Action/CI step into one real deploy job.
Run the check against a real deploy, wherever you run it — a staging environment or straight to production.
You define what "approved" means for your team — we enforce it.
