Libra boots every pull request in a disposable sandbox and runs it against the production traffic that already hits the code it changed. Then it stays on after the deploy, watching the same systems, so the failures replay could not predict still get caught at 3 AM instead of by a customer.
Point it at one repository and one cloud account. You will see runs on your own code the same day.
Works with the stack you already run
Reading a diff can only tell you what the code says. Libra runs it, which is the only way to find out what it does.
Every pull request boots in a throwaway microVM and runs against the traffic that actually hits the code it changed. The reviewer gets an execution record: what ran, what passed, and what could not be tested.
Libra reads logs, traces, deploys, cloud infrastructure, and product analytics continuously, learns what normal looks like for your business, and opens the incident before anyone is paged.
What a sandbox run actually does
A run reports the coverage it achieved, including the layers it had to skip and why. A reviewer can see the difference between “this was tested and passed” and “this was never reached.”
Install, typecheck, build, and the repo's own test suite, on the PR branch. Catches what slips through when the author never ran them locally.
Replays the real requests that recently errored in production against the PR build, and compares the span status before and after. This is the layer no static reviewer has.
Reads the diff and calls the endpoints the PR actually changed, with a stated rationale per call. Covers new code paths that no existing trace touches.
Drives the user-facing flow end to end, so a change that builds and returns 200 but breaks the screen still gets caught.
[ Security ]
The controls that matter here are the ones that hold when something goes wrong, so each one below is enforced in the product rather than promised in a policy.
Libra reaches your AWS account through a cross-account role scoped to ReadOnlyAccess, gated on an external ID, with one-hour sessions. It cannot change your infrastructure.
Replay refuses to write to any database it cannot prove is disposable. A connection string it cannot parse is treated as production and protected.
Each PR runs in its own microVM that is destroyed when the run ends. Staging secrets are decrypted at dispatch and never persisted outside it.
A platform team and a product team do not want the same checks. Libra is scoped per repository, so each one carries its own build, its own environment, and its own rules about what may be touched.
Turn replay on repo by repo. Each one carries its own build commands, test env, and the database it is allowed to touch.
Libra discovers your staging environment from your own ECS task definitions and secret stores, scoped so production is unreachable. No bundle to maintain by hand.
Every correction someone gives it in a Slack thread becomes context for the next incident on that service.
The same tools Libra investigates with are callable from Claude Code or any MCP client, so your engineers can pull the evidence themselves.
Ways Libra plugs into your workflow
Libra lives in the channel your team already watches. Reply in the thread to ask it questions and it answers with evidence attached.
Results arrive where the reviewer already is: one Check Run per commit, and findings as exact-line threads on the diff.
Traces, deploys, incidents, and sandbox runs are queryable from your own agents and editors over MCP.
Libra routes across Anthropic, OpenAI, and Google models and picks per task. You are not tied to one vendor's roadmap.
Nothing about the evaluation depends on a curated demo. Connect one repository and one cloud account, and judge Libra on the pull requests your team opens this week.
Yes, on the Enterprise plan. Libra runs in your own cloud account so customer code, traces, and secrets never leave your environment. Talk to us about the deployment shape you need and we will scope it with you.
No. Replay boots against a staging environment, and the AWS permissions that discover it are scoped to staging resources, so production is unreachable even if the code tried. Recorded production traces are replayed as request payloads against that staging build, not against production itself.
Not unless you explicitly hand it a disposable one. If the configured database looks real, replay runs read-only and skips every write request, and says so in the PR. Anything it cannot prove is disposable, including a connection string it cannot parse, is treated as production. It fails safe.
GitHub today, through the Libra GitHub App using short-lived installation tokens. GitLab is supported for reading deploys and merge requests. If you are on something else, tell us what and we will give you a straight answer on timing.
Replay is scoped per repository and per changed path, so a PR only boots and exercises what it touched. Base images are baked per repo, which is what takes a cold install of ten minutes down to seconds on subsequent runs.
Point it at one repository and one AWS account. Within a day you will see real PR runs and real production findings on your own code. Nothing about the evaluation depends on a curated demo.
Unlimited connected accounts, SSO and SAML, the self-hosted option, and dedicated support. Pricing is scoped to your org rather than per seat.
Not answered here? .