Egret

How it works

Your runs, collected. Drift, surfaced. On your infra.

The agent writes a report for every run. Egret Nest is the optional place those reports go - so a fleet of CI jobs becomes history, drift, and a fleet-wide view. It's a single Go binary you host yourself.

  1. 1

    An Egret run POSTs its report

    When you set EGRET_INGEST_URL, each Egret run sends a versioned Envelope (schema_version 1) to POST /ingest, authenticated with a bearer ingest token. Unset the URL and nothing is ever sent - the agent never requires Nest.

  2. 2

    Nest records runs, repos & endpoints

    It parses the report and stores what each CI job connected to - allowed, flagged, and blocked - per run and per repository, with the full history over time.

  3. 3

    It computes new-endpoint drift

    Each run's endpoints are compared against your baseline. Newly-seen endpoints are surfaced first - the earliest signal of a dependency change or a supply-chain compromise.

  4. 4

    You browse it, access-controlled

    A dashboard with run history, per-repo and org-wide rollups, org RBAC (owner / admin / member / viewer), and the auth trilogy (local + TOTP / GitHub OAuth / OIDC). All on your own infrastructure - the data never leaves it.

The invariant

Never required. Always optional.

No headline feature of the Egret agent ever requires Nest. The agent is server-agnostic - it only talks to Nest when you set EGRET_INGEST_URL, and the report is sent over TLS with a bearer token you control (Egret refuses to send the token over cleartext HTTP).

What it needs

One binary, your own infra.

  • A single static Go binary (pure-Go SQLite, no CGO) - or the Docker image
  • A 32-byte EGRET_NEST_SECRET_KEY (encrypts TOTP seeds + SSO secrets at rest)
  • TLS natively, or behind your own proxy

All Nest features → · Install options → · The ingest contract →