Agent-based (push) CI analytics
Agent-based CI analytics runs a small process inside your network that pushes pipeline data out over HTTPS — the way to analyze a self-hosted CI the vendor cannot reach.
What is agent-based (push) CI analytics?
Agent-based (push) CI analytics is an integration model in which a small program — the agent — runs inside the customer's own network, reads pipeline data from a CI system there, and pushes it out to the analytics service over outbound HTTPS. It is the alternative to the pull model, where the service calls the CI provider's API directly, and it exists for CI instances the service cannot reach: self-hosted GitLab behind a VPN, Jenkins in a private subnet, anything without public ingress.
Push vs pull
| Pull (vendor calls the CI API) | Push (agent inside the network) | |
|---|---|---|
| Network requirement | CI reachable from the internet | Outbound HTTPS from one host |
| Who holds the CI token | The vendor | The customer's agent host |
| Trust question | How far can the vendor reach in? | What can the agent send out? |
| Boundary enforced by | Vendor's client code | Agent code (auditable) + the receiving API's schema |
| State | Vendor keeps sync cursors | Ideally the vendor still keeps them (stateless agent) |
Properties of a well-designed agent
- Outbound only — nothing listens on a port reachable from outside the host.
- Open source and small, ideally with no third-party dependencies, so it can be audited fully.
- An explicit endpoint allowlist in code, refusing any CI API call outside pipelines, jobs, and traces.
- Stateless — the service remembers how far each project was synced, so a replacement agent resumes correctly and there is no local file to back up or migrate.
- Bounded data — a documented set of fields leaves the network; the receiving API has no fields for source code, diffs, or CI configuration.
- Hashed credentials on the vendor side — the agent's own token is stored as a hash, so a database breach yields nothing usable.
Where TrimCI uses it
TrimCI's cloud integrations for GitHub Actions and gitlab.com are pull-based. For self-hosted GitLab behind a VPN or private network, the open-source TrimCI Agent implements the push model with exactly the properties above; the monitoring self-hosted GitLab CI behind a VPN guide compares it with the alternatives.
See what your CI failures actually cost.
Connect GitHub Actions or GitLab CI with read-only access — we never request repository contents, only pipeline runs, jobs and failed-job log excerpts — and get a ranked, dollar-costed fix list from your own data.