? The guide
How Trevo works, with something real to click.
Seven short chapters for the person setting Trevo up and the engineer reviewing it. Each chapter links to the exact screen it explains in a seeded demo workspace, so you can check the product while you read.
Trevo in three minutes
The whole arc — observe, propose, pull request, measure, ship — on one page.
3 min · demo: open the workspace02Connecting GitHub and choosing repositories
The account is the GitHub sign-in. The permission model is the first thing an engineer checks.
4 min · demo: see the connected repo03Installing the SDK and verifying events
Client and server, one identity, and the green tick that means it is live.
5 min · demo: see the events arriving04How proposals get written
The repo scan, the evidence chain, and why a proposal can exist before any traffic does.
5 min · demo: read a proposal, then approve it05Approving, reviewing the PR, and what Trevo never touches
The branch policy, the experiment gate, the temporary clone.
4 min · demo: read a pr the bot wrote06Reading results and shipping a winner
The verdict, the three tiles, how to read “Too soon to tell”, and the cleanup PR.
5 min · demo: read a called, shipped result07Teams: inviting people, roles, and the audit trail
Who can approve, who can merge, and how every decision is recorded.
3 min · demo: see the decisions on record• Security & your data
What Trevo sees, keeps, and hands back.
Trevo has the access a contractor on their first day would get — read on your default branch, write only on trevo/* branches, and never a merge without you. Here is exactly what that means for your code and your data.
Do you own or keep a copy of our code?
No. Your code stays yours — connecting a repo gives Trevo no ownership of it and no license beyond writing the pull requests you approve. Trevo never stores a copy of your source. When it writes a variant it clones your repository into a temporary workspace that is deleted the moment the job finishes. The only thing it keeps is a structural map of your app — a list of routes, components, and server-side logic with file paths and short descriptions — so it knows where a change would go. That map lives in your workspace alone and is deleted when you disconnect.
What exactly can Trevo see?
What a new teammate opening your repository could see, and nothing more: the files in the repositories you choose to connect, read through a GitHub App you install and can revoke at any time. It has read access to your default branch and write access only to trevo/* branches — it cannot push to main, and your own branch protection enforces that too. Every change it makes lands as a commit with its name on it, and an append-only audit log records who approved what.
Do you train an AI model on our code or our metrics?
No — nothing in your repository or your experiment metrics is used to train models, ours or anyone else's. When Trevo drafts a variant it sends a model only the slice of your repo needed for that specific change, and only to produce that one pull request. We rely on a small set of third-party model and infrastructure providers to run the scan and draft PRs, and we're happy to share that list on request.
How do experiments ship — could Trevo break production?
Trevo never deploys and never merges. It opens a pull request; your engineers review and merge it exactly like any other PR, through your existing CI and checks. Variant assignment then runs inside your own code from a synced config snapshot — there is no blocking third-party script in your critical path. Starting an experiment only flips traffic on code you already merged, and if you do not like a variant you simply close the PR and nothing changes.
What happens to our data if we disconnect?
Disconnecting the repository or uninstalling the GitHub App immediately invalidates Trevo's access and deletes the structural maps it built. Deleting your workspace purges the rest of your data, including any stored payloads, from our systems. You can do either yourself, at any time, without contacting us.