What it takes to run Odonat in your VPC.
Four steps from an empty namespace to a Shadow Replay running against your own production traffic. Everything below happens inside your perimeter, and the first stage changes nothing.
Install the agent in your cluster
A Helm chart deploys the agent into a dedicated odonat-system namespace on your own EKS, GKE or AKS cluster. It runs non-root on a read-only root filesystem, opens no ports, and reaches everything it needs by outbound connection. Nothing in your environment ever dials in to it.
Connect source control
You register a GitHub or GitLab app scoped to read repository contents and checks, and to write pull requests. It cannot force push and it cannot alter branch protection. That scope is what lets Odonat see a diff before it merges, and draft a revert after one lands.
Point telemetry at it
Your existing Datadog and PagerDuty webhooks get a second destination inside your cluster. Alerts normalise into a single IncidentEvent shape so the causal engine can correlate them against recent deploys and config changes. No agent goes on your app servers and nothing enters your request path.
Set the safety plane, then start in shadow mode
You choose the confidence threshold, which services are eligible for autonomous action, and where sub-threshold proposals get routed for approval. Every deployment starts in shadow mode: Odonat watches, drafts what it would have done, and changes nothing until you have read enough of those drafts to trust the judgement.
Four objects. Read them before you apply them.
The chart is plain YAML with no templating tricks, and it is short enough to review in one sitting. Your platform team should read it rather than take our word for the permission boundary.