Security and data

What Pitstop can reach, where your code goes, and the part that is not finished yet.

Permissions the App requests

Contents: read & write — to clone your repository and push a redline/* branch
Pull requests: write — to open one, and to close it when a later run withdraws the fix
Checks: write — to report the run's outcome on your commit
Metadata: read — mandatory for every GitHub App

Scoped to the installation you choose. Pitstop cannot see any repository you have not added, and removing one in GitHub stops its runs immediately.

What it will not do to your repository

It never pushes to your default branch. Every commit goes to a branch named redline/…, and a guard raises rather than writing anywhere else — including a refusal to commit while the working tree is on the default branch at all.
It never merges anything. Every change is a pull request for a person to read and decide on.
It never force-pushes over work it did not create. Replacing its own stale branch uses a lease that fails if anyone else moved it.
A rejected patch is deleted from the remote as well as locally. A branch nobody could prove should not sit where somebody might merge it.

Where your code goes

Cloned into a container that exists for one run and is destroyed when it ends.
Your build command runs there. Measuring a site means building it, and building it means running whatever your package.json says.
Screenshots and Lighthouse reports go to a private bucket so the dashboard can show them, and are deleted after 90 days. They are served through short-lived signed links, never published.
Findings, patches and verdicts are stored so the dashboard can show what was decided and why.
Nothing goes to any third party. No analytics, no tracking, no telemetry.

The part that is not finished

Your build command runs on our infrastructure, and today that container shares a service-account identity with the service that stores run records. A repository whose build script was hostile could reach further than its own run. The GitHub App's private key is deliberately not in that container — it stays in the web service, which issues a token scoped to a single installation for each run — so the worst case is one installation rather than every installation. Isolating the build properly is the next piece of work.

Which is why this is open to people who know us, and not to open signup. If that trade is not one you want to make, the honest answer is to wait.

Reporting something

Found a problem? Open an issue on the demo repository, or email the address on the account that owns the App. Please do not file a public issue for anything you think is exploitable — say that you have something and we will find a private channel.