Ship freely.
Gate the exceptions.
Continuous deployment works because it removes ceremony. The answer is not to add ceremony back for every change — it is to gate the small set of deploys that bypass your normal safety net.
Which deploys actually need a gate
If you require sign-off on every release, one of two things happens: velocity collapses, or approval becomes a rubber stamp and you have added latency without adding safety. Neither is worth having.
The deploys worth gating are the ones that already skip a control you rely on the rest of the time.
- Hotfixes merged without review — the emergency path around your pull-request requirement.
- Out-of-hours deploys, when the people who would notice breakage are asleep.
- Rollbacks that reverse a migration, which can be more destructive than the release they undo.
- Anything touching auth, billing, or data retention, regardless of size.
- Deploys during a change freeze — the freeze is your control, so its exception path is what needs the gate.
Approvals that survive the pipeline being compromised
A pipeline approval implemented purely inside your CI provider is worth exactly as much as the CI provider's access controls. Anyone who can edit the workflow file, or who holds a token with enough scope, can remove the gate or fake the approval, and supply-chain attacks target precisely that.
Because TeamSigner approvals are signatures made on approvers' own devices over the specific request, forging one requires the private keys, and those exist only on phones. Your deploy endpoint verifies the signatures itself against a list of member public keys it holds. A compromised runner can raise a request; it cannot manufacture the approvals.
Keeping the record
Each approved deploy leaves you a delivery containing the exact signed pre-image, the signatures, and the public keys behind them. Store the payload alongside the release. When someone asks in six months who authorised the Friday-evening billing deploy, the answer is a verifiable artefact rather than a chat log.
Common questions
Won't this break continuous deployment?
Only if you gate everything. Applied to the exception paths — hotfixes without review, freeze-window deploys, migration rollbacks — the great majority of releases are untouched.
How is this different from GitHub environment protection rules?
Protection rules are enforced by the platform and trusted on its say-so. TeamSigner approvals are cryptographic signatures your own service verifies, so the evidence survives independently of the CI provider and of us.
Can the approval be tied to a specific commit?
Put the commit SHA in the request message. It is covered by the signatures, so an approval for one commit cannot be presented as approval for another.
Put a threshold on it.
Define the action, pick how many approvals it needs, point it at your webhook. Free while we're getting started.
Log in & get startedIntegrating? The full webhook contract is in the docs.