Early access · CD gatekeeper for GitHub Environments

Cryptographic deployment approvals for GitHub Environments

wardenv moves approval authority out of GitHub — to the identities you choose — and anchors every approval, rejection and timeout in a tamper-evident transparency log.

ci · deploy pipeline
$ gh run watch --exit-status build 1m12s test 2m48s deploy → production waiting for approvalwardenv · deployment protection rule request release-managers@acme-idp decision APPROVED · ed25519:9f2c…a1d4 evidence rekor.sigstore.dev · entry 92841730 deploy → production released

// the problem

GitHub approvals stop at your organization's boundary

Environment protection rules are a good start — until approvals must come from outside GitHub, or must be proven to someone outside your company.

Org-bound identities

GitHub approvals require approvers to be members of your GitHub organization. Vendors, partners, customer-side approvers, an on-call rota in another IdP — workarounds, shared accounts, or no approval at all.

Clicks, not proof

A button click in a web UI is not a signed statement. When an auditor asks who approved a production change and under which identity, “the GitHub UI says so” is not evidence.

Regulated change management

Critical infrastructure operators must demonstrate separation of duties and produce tamper-evident records for every production change — across organizational boundaries.

Ephemeral trails

Approval context lives inside workflow run logs with limited retention. When the run is gone, so is your audit trail — unless you export it yourself, every time.

// how it works

A gate between “merge” and “production”

wardenv sits on GitHub's deployment protection rule API. Nothing reaches a protected environment without a signed decision — and every decision leaves permanent evidence.

protection rulerelease / blockapproval requestsigned decisionevidence anchoredGitHub Actionsenvironment: productionwardenvCD gatekeeperExternal approverany IdP · any realmrekortransparency log
  1. 01

    Protection rule attached

    wardenv registers as a custom deployment protection rule on your GitHub Environment.

  2. 02

    Deployment intercepted

    When a workflow targets the environment, wardenv receives the callback and holds the pipeline.

  3. 03

    Approval delegated

    The request goes to identities in the realm you choose — an external IdP group, a partner, an on-call rota. No GitHub seat needed.

  4. 04

    Decision signed

    Approve, reject, or let it expire. Each outcome is a signed statement bound to a verified identity.

  5. 05

    Evidence anchored

    The decision lands in the rekor transparency log and the deployment is released or blocked. The record outlives the pipeline.

// features

Approvals you can prove, not just point to

External identity delegation

Delegate approval authority to any identity provider or realm — contractors, partners, customer-side approvers — without handing out GitHub access.

Cryptography, not clicks

Every decision is a cryptographically signed statement, bound to a verified identity and to one specific deployment — not a UI click in an audit log.

Standard evidence store

Decisions are anchored to rekor, the Sigstore transparency log: tamper-evident, append-only, and verifiable by anyone — including your auditors.

Timeouts on the record

No response is a response. Expired and rejected approvals are logged with the same rigor as approvals — silence is auditable too.

Built for OT compliance

Designed for change management in critical infrastructure: separation of duties, demonstrable audit trails, and evidence you can export.

Native GitHub integration

Hooks directly into Environment deployment protection rules. Keep your existing Actions workflows — wardenv only adds the gate.

// evidence

Evidence that outlives the pipeline

Every wardenv decision is anchored to rekor, the Sigstore transparency log — the same standard that secures the open-source supply chain. Each entry proves:

who
The verified identity that signed — from whatever realm you delegated approval to.
what & when
The exact deployment, the decision, and the timestamp, captured as one signed statement.
forever
Entries are append-only and independently verifiable against the public log.

Verification never requires wardenv. Auditors check entries against the public transparency log directly — no vendor access, no lock-in.

audit · evidence lookup
$ rekor-cli get --uuid 7f3a…9b2eidentity: release-mgr@partner-realmdeployment: acme/billing-api#4821 → productiondecision: APPROVEDsignature: ed25519:9f2c…a1d4timestamp: 2026-08-12T14:03:11Zintegrated: rekor.sigstore.dev · entry 92841730

// compliance

Built for critical infrastructure

Change management in OT environments is not a workflow convenience — it is a regulatory obligation. wardenv is designed to support programs such asIEC 62443 and NERC CIPby producing the signed, tamper-evident evidence your auditors ask for.

wardenv supports your compliance program; it is not itself a certification.

  • Enforceable separation of duties — approver and deployer never share an identity plane.
  • Portable, verifiable evidence for every production change, ready for audit export.
  • Approval authority stays inside your own IdP — fits operator models in regulated and OT environments.
  • Approval, rejection and timeout are all first-class, recorded outcomes — nothing falls through the cracks.

// contact

Request early access

Tell us about your environment — protected deployments, identity providers, compliance drivers — and we'll come back with a demo and early-access terms.

Prefer email?hello@wardenv.dev

Submissions are protected by Cloudflare Turnstile and processed as described in our privacy notice.