Find your first useful gate.
$0
One private repository.
Unlimited agents. Public repositories always free.
- Policy enforcement and signed evidence
- Clear reasons when a push is refused
- Public repositories included
For developers and AI agents
Faster feedback.
Before the push.
CI is the bottleneck for AI coding. Your agent writes the code, then pushes, waits, and fixes. Over and over.
Your required checks run on your own compute. Pushgate verifies the signed evidence against your policy and refuses a push that falls short.
Free for one private repository. Setup takes a TestifySec account, a passkey for approvals, a GitHub repository and the cilock CLI.
The old loop
Push. Wait. Fail. Repeat.
- Agent writes code 10s
- Push to remote 5s
- Wait for CI to run 6+ min
- Find failing checks 10s
- Agent fixes code 30s
- Push again 5s
- Wait for CI again 6+ min
- Failed.
Repeat.13+ min
With Pushgate
Feedback where your agent works.
- Agent writes code 10s
- Run required checks
on your compute 30s - Fix issues (if any) 20s
- Push with evidence 5s
- Accepted.
Move forward.65s
Illustrative timings for one cycle. Not a benchmark.
Bring the agents
you already work with.
✳ Claude Code
⌘ Codex
↗ Cursor
⌥ OpenCode
Any Git-capable agent →
Fewer CI round trips
Find and fix issues before pushing, not after.
Enforce your standards
Require evidence for the checks you care about.
Use your own compute
Run checks in your environment. No extra runner bills.
Built for agent workflows
Let agents move fast, with real accountability.
The problem
AI coding moves fast.
CI can’t keep up.
Agents can generate, test, and iterate in seconds. Traditional CI forces a slow, expensive feedback loop on top of that. The result is wasted time, higher costs, and frustrated developers (and agents).
SAMPLE
> agent: implement user authentication
> git push
◷ Running CI... (6m 12s)
✕ 3 tests failed
> agent: fix issues
> git push
◷ Running CI... (5m 48s)
...
The solution
Your compute. Your checks.
Your rules.
Pushgate verifies that your agent’s changes meet your requirements before they’re pushed. Run the checks where your agent works, on your infrastructure, and make the results count.
- Run your existing checksUse the tools and environments you already have.
- Cryptographic evidenceResults are signed and tied to the exact change.
- Enforce before the pushUnmet requirements block the push.
- Cheap (or free) by designNo CI-minute bill. The checks run on your compute.
Compared
Faster runners shorten the wait.
Pushgate removes the trip.
Hosted CI, fast or slow, runs your checks on its machines and enforces them after you push. With Pushgate, your checks run on your machines before you push, and a push without passing evidence is refused.
Your agent
Pushgate checks here
push
Hosted CI checks here
GitHub
| Axis | GitHub Actionshosted runners | Fast hosted CIRWX, Depot, Blacksmith | Chainguard Checksbeta |   Pushgatebefore the push |
|---|---|---|---|---|
| Where your checks run | GitHub-hosted runnersor self-hosted runners you operate | Their build infrastructureisolated, provisioned by the provider | Their microVMsenvironment built from your lockfile | Where your agent already worksyour laptop, your runner, your cluster |
| When results are enforced | After the pushas a required check on the pull request | After the pushas a required check on the pull request | After the pushas a required summary check; a run before the push is advisory unless your agent loop requires it | Before the push is accepteda refused push never reaches GitHub |
| What the agent gets back | A failed check, minutes laterread the log, guess, push again | A failed check, soonersame round trip, shorter wait | Structured failureswhen the agent calls it before pushing | The missing requirementinside its working loop, before it pushes |
| What you pay for compute | Per minuteon hosted runners | Per minute or per seaton their machines | Metered computea free monthly allowance, then per use | Nothing extrayou already own it; plans are per developer |
| What a pass is backed by | Logs and a check status | Logs and a check status | A signed attestationsigner and format not stated in the launch material | Signed evidencebound to the exact commit |
| Provenance of the change | Workflow logs | Workflow logs | Environment, verdict, commitrecorded by their runner | Signed provenancewhich command ran, where, by whom, on which commit |
| Your existing pipeline | Is the pipeline | Swaps in their infrastructure | Port the steps to their configthe environment is declared as a package list | Shrinks to the merge queueeach PR is tested by its own agent before the push; integration tests run once, in the queue |
| Run it on your own infrastructure | Runners onlythe service stays GitHub's | Hosted by the provider | Not documentedat beta launch | Yes, with the Enterprise applianceyour cloud or on prem, with your own signing root; the push is refused there too |
Keep CI for what only CI can do: integration environments, release builds, deploys. Move those into the merge queue, where they run once per merge. The per-PR checks run where the agent works, before it pushes.
Chainguard Checks can also run before the push, so it is a runner, and a good fit for the “run anywhere” part. Pushgate is the gate above whichever runner you use: it decides whether the result lets the push land. Comparison drawn from Chainguard’s public beta documentation, October 2026.
How it works
Three steps. One remote.
-
1
Point your agent at Pushgate
Connect a repository and give your agent the Pushgate push URL. Your Git workflow stays the same.
-
2
Run the checks where the agent works
Your tests, linters and scanners run on your machine or your runner.
cilocksigns the result and binds it to the exact commit. -
3
Push with evidence
Pushgate verifies the evidence against your policy. A missing requirement comes back as the next step. A satisfied one goes through.
agent / checkout-serviceSAMPLE
$ git push pushgate HEAD
↳ push needs attention
Required: passing test evidence
Commit: a81f9c2
$ cilock run --step push-tests -- npm test
✓ 42 tests passed · evidence signed
$ git push pushgate HEAD
↳ policy passed · push accepted
Your tools execute the checks. Pushgate verifies the evidence.
Start small. Expand when it works.
Priced for your team.
Every agent is included.
Prove the workflow on one repository, then bring the team.
SELF-SERVE
DEVELOPER
Gate every repository.
$8.99/ developer / month
Billed monthly.
1-3 developers.
- Unlimited private repositories
- No push limit
Put the team behind the gate.
$29/ developer / month
Billed annually.
$39 per developer when billed monthly.
- Unlimited repositories and agents
- Full decision retention
- Priority support
Fit your environment.
Let’s talk.
Custom annual agreement.
Deployment and support scoped with you.
- Customer-controlled deployment
- Identity and procurement requirements
- Defined infrastructure and support costs
Paid plans use a sales-assisted handoff. View full pricing and plan details →
The platform for developer and agent trust
One checkpoint.
Part of a wider platform.
Start with Pushgate for one repository. The TestifySec platform manages the gates across your team and connects test results to technical controls.
Capture the work.
Capture signed evidence from builds, tests, and scans on your compute or hosted infrastructure.
Explore CI/lockCheck the push.
Require evidence before a push enters your repository through the gate.
Read Pushgate docsManage gates. Reuse the evidence.
Manage repository gates and connect technical test results to compliance controls.
Explore the platformPlatform features, appliance deployment, and platform pricing live on testifysec.com. Start with the Pushgate getting-started guide, then explore the related product docs.
Straight answers
A decision should
come with an explanation.
See the evidence behind an accepted change.
Understand the boundaries of the guarantee.
What does a passing decision mean?+
It means the supplied evidence satisfied the configured requirements. It does not prove all possible bugs were found, that the tests were sufficient, or that the change is ready for every deployment environment.
Can an agent just sign a claim that it passed?+
A signature identifies a signer; trust also depends on the evidence producer and execution environment. A policy must define which evidence it accepts. The signed result alone does not make a weakened test suite reliable.
What if someone pushes around the gate?+
Pushgate checks only pushes sent through it. Your repository permissions must prevent unauthorized direct pushes to GitHub. A gated remote cannot enforce requirements on a route that bypasses it. Check the entire route during setup.
Do I have to replace my CI pipeline?+
No. Start with one repository and one requirement. Keep the integration, environment and release checks you need.
Your next push can be the start.
Give your agent a clear way through.
Get started freeConnect one repository. Send a signed push. Choose your rules.