The trust boundary in plain language.

Pushgate is not a permanent repository. It verifies and forwards Git packs. When delivery is queued, pack bytes may be stored encrypted at rest for up to 24 hours and are removed after successful delivery. The durable ledger keeps identities, commit digests, decisions, and timestamps. If bytes expire, the ledger/FIFO barrier remains; an operator must retire the barrier and the branch must be pushed again.

For the basic command policy, it proves that a command bound to the exact repository and commit exited zero under the credential that signed the record. It does not prove the command was the test suite you intended, or that the suite was sufficient. Richer test-result, scan, and policy semantics require the corresponding evidence and enforcing policy.

A verifier checks the DSSE signature, certificate trust, trusted timestamp, subjects, and policy. Changed bytes, an untrusted credential, or a record bound to another commit are rejected. The remaining trust boundary is the execution environment: evidence says what CI/lock observed under its signing credential, not that the machine itself was incorruptible.

A GitHub repository ruleset must restrict protected refs to the Pushgate App identity. Until that rule is enabled and verified, Pushgate is an advisory path: a writer with direct GitHub permission can bypass it. The Git remote alone is not the complete enforcement boundary.

Pushgate can verify a push independently, retain an approved pack for up to 24 hours, and retry delivery in repository order. Delivery stops on an upstream conflict instead of overwriting it. Conflicts and expired pack bytes require intervention; Pushgate never promises that every queued push will deliver without another push.

Not all of it. Deterministic tests, lint, and scans can run close to the agent under CI/lock. GitHub CI remains the right place for protected secrets, cross-platform matrices, shared integration environments, release signing, deployment, and independent spot checks.

Pushgate repository assignment is separate from a platform Product binding. The effective policy and enforcement mode are visible on the repository connection. Signed policy artifacts use immutable identifiers and digests as authority—never a movable name, tag, or “latest” lookup. Policy authoring stays in CI/lock and the platform, not in a second Pushgate editor.

Yes. CI/lock is open source: fork Rookery and compile the distribution your environment needs. Pushgate verifies the evidence, not the executable that produced it. What it checks is tenant-scoped evidence for the exact pushed commit, supported DSSE-signed in-toto predicates, accepted signer trust, and an RFC 3161 timestamp. A new predicate URI must appear in the platform's compiled or tenant-observed library before policy activation, and typed server behavior also needs evaluator support.

That is part of Pushgate Enterprise at ALPS 3, and ALPS 3 is not available today. The design: TestifySec will build and sign your customer-specific CI/lock binary and run its signing in an isolated service (cilockd) with a non-exportable identity, as ALPS 3 requires, so the coding agent receives a typed proof interface, never the protected key material. cilockd has not shipped, so no environment reaches ALPS 3 yet; the support matrix at /docs/support-matrix shows the status of each level.

We have a GitHub Actions baseline, but not yet a production-quality client-observed Pushgate decision distribution. The server stages are instrumented; the matched client collector is designed but not deployed, so the site publishes no speedup multiplier. The report will compare the same commit, workload, cache state, region, and boundary with sample counts and p50/p90/p95—not a Git advertisement request against an entire CI run.

Free covers one private repository and up to three developers, with unlimited agents. Business is $29 per developer per month billed annually, or $39 billed monthly, with unlimited repositories and agents. Enterprise is a custom annual contract. Paid provisioning is sales-assisted today; self-service checkout is not live yet.

Yes. The customer-controlled appliance can run in AWS, Google Cloud, Microsoft Azure, or fully on-premises on customer-owned infrastructure. Deployment sizing states required compute, storage, availability, and cloud or equipment costs separately from the Pushgate subscription.