{"slug": "pushgate", "title": "Pushgate", "summary": "Pushgate launched as a checkpoint that sits between a coding agent and GitHub, blocking pushes that fail a repository's configured tests and security checks. The product verifies signed evidence for the exact change and returns unmet requirements to the agent's working loop, with no per-agent fees and support for existing Git workflows. Pushgate states it checks only pushes sent through it, so repository permissions must prevent unauthorized direct pushes to GitHub.", "body_md": "### Tests & coverage\n\nUnit tests, integration tests, coverage thresholds and mutation tests using your project’s tools.\n\nPushgate is a checkpoint between your coding agent and GitHub. Choose the tests and security checks you require. Pushgate blocks pushes through it that don’t meet your rules.\n\n✓ Keep your Git workflow ✓ No per-agent fees\n\nBring the agents**you already work with.**\n\n\t\t\t\t\t\tA missing check becomes the next step.\n\nWatch a push go from missing evidence\n\nto an accepted change.\n\t\t\t\t\t\n\nA commit, with evidence attached.\n\nMissing requirement? A clear reason.\n\nComplete the work. Submit the evidence.\n\nInspect the decision and its evidence.\n\nrepository acme/checkout-service\n\ncommit a81f9c2\n\nstatus ready to push\n\nRun the example to see the gate in action.\n\nReturn the unmet requirement directly to the working loop.\n\nEvaluate the change against the repository’s selected policy.\n\nUnderstand the checks and evidence behind the decision.\n\nA policy is your repository’s list of requirements. \n\nUse a built-in check or bring your own commands.\n\nBuilt-in secret scanning. Go vulnerability checks and other dependency scanners use a custom command policy.\n\nRequire your formatter, linter or type checker to pass before a push goes through.\n\nCheck dependency rules, API contracts or module boundaries with your team’s scripts.\n\nRun your infrastructure validators, container checks and configuration tests.\n\nAdd an accessibility check, a performance budget or a project-specific validation command.\n\nThese are examples of requirements you can configure, not checks that all run automatically. A coverage or performance threshold needs a command that fails when the limit is missed. Pushgate verifies the signed result for the exact change.\n\nYour team decides what a change must prove. Select a policy for each repository and give agents a consistent answer.\n\nSee each repository and its selected requirements.\n\nReview the exact policy before changing a repository’s requirements.\n\nConnect each result to the policy used to evaluate it.\n\n\t\t\t\t\t\t\tIllustrative configuration only. This example does not change any repository or show a current bulk rollout feature. Today, an\n\t\t\t\t\t\t\tauthorized person selects and approves each repository’s policy. [Explore available policies →](https://pushgate.dev/policy)\n\n\t\t\t\t\t\tWhen trusted checks have already run for\n\nthis change, verify their evidence and run\n\nwhat remains. Explore the\n\t\t\t\t\t\tdifference.\n\t\t\t\t\t\n\nReusable means valid evidence for this exact change, from an execution environment your policy accepts.\n\nless waiting per verification cycle\n\nBoth paths satisfy the same defined check requirements. Timing starts after the change and any reusable check results exist; that earlier work is excluded equally. CI queues and reruns all checks. The Pushgate path runs the remaining checks immediately in an approved environment and adds an illustrative 3 seconds for evidence verification. We approximate reusable execution time linearly. Any additional queue, evidence-production overhead, merge checks, hardware tests, release checks or human approval must be included in a real measurement. This is a scenario, not a benchmark or a promise of delivery-time savings.\n\nSee the evidence behind an accepted change.\n\nUnderstand the boundaries of the guarantee.\n\nIt 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.\n\nA 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.\n\n\t\t\t\t\t\t\tPushgate checks only pushes sent through it. Your repository permissions must prevent unauthorized direct pushes to GitHub.\n\t\t\t\t\t\t\tA gated remote cannot enforce requirements on a route that bypasses it. [Check the entire route during setup.](https://pushgate.dev/docs#protect-the-route)\n\nStart with one repository and one requirement. Keep the integration, environment and release checks you need. Reuse results only where they provide equivalent evidence for the required check.\n\nProve the workflow on one repository, then bring the team.\n\nOne private repository.\n\nUp to 3 developers. Unlimited agents.\n\nBilled annually.\n\n$39 per developer when billed monthly.\n\nCustom annual agreement.\n\nDeployment and support scoped with you.\n\nPaid plans use a sales-assisted handoff. [View full pricing and plan details →](https://pushgate.dev/pricing)\n\nConnect one repository. Send a signed push. Choose your rules.", "url": "https://wpnews.pro/news/pushgate", "canonical_source": "https://pushgate.dev/", "published_at": "2026-09-22 12:40:23+00:00", "updated_at": "2026-09-22 12:54:26.309126+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-tools"], "entities": ["Pushgate", "GitHub"], "alternates": {"html": "https://wpnews.pro/news/pushgate", "markdown": "https://wpnews.pro/news/pushgate.md", "text": "https://wpnews.pro/news/pushgate.txt", "jsonld": "https://wpnews.pro/news/pushgate.jsonld"}}