Arbor Cloud
Pull request checks, on GitHub.
Arbor Cloud adds one quiet “Arbor impact” check to pull requests in the repositories you choose. It lists what the change reaches, the called functions with no test found and where to start reading, and saves a private report. Sign in with GitHub to start; your first 3 pull requests are free.
No card for the trial. Checks are off until you turn them on for a repository. Each run asks GitHub for read-only access to the one repository it analyzes, and the check is written with a token limited to checks.
Where things stand.
- Open-source engine
- Available on GitHub, MIT licensed
- Arbor Cloud
- Open
- Trial
- 3 pull requests per GitHub account, no card
- Developer
- $19 a month per workspace
- Team
- $79 a month per workspace
- Previous Cloud
- Closed September 23, 2026
What the check shows.
- What it reaches
- Entry points whose calls lead to the changed functions. An entry point is a function that looks like a route, handler, job or command by its file and name, and that no production code calls.
- What to test
- Changed functions with callers outside tests and no test found. That means the graph shows no test calling the function within four calls, and no test file names it. It doesn’t mean the function is untested.
- Where to start reading
- Changed files ranked by the entry points they reach, the sensitive areas they touch, their functions with no test found and their callers, with owners from your CODEOWNERS file.
- Dependencies
- Advisories from OSV for package versions the pull request added or updated in
Cargo.lock,package-lock.jsonornpm-shrinkwrap.json. Other lockfiles, such asyarn.lockandpnpm-lock.yaml, aren’t checked. - What Arbor couldn’t see
- This run’s own gaps, and the calls it can’t follow, such as reflection, dynamic imports, configuration and HTTP.
- Result
- Neutral: a map for review, not a verdict or a risk score. On Team, rules in
.arbor/checks.ymlcan fail it, and a member with write access can override that for a commit.
Turn checks on.
Checks are off for every repository until someone turns them on. Without that step, your pull requests get no check.
Sign in with GitHub
Your first 3 pull requests are free and need no card. They’re shared by every workspace your GitHub account creates.
Install the Arbor GitHub App
Choose the repositories it may read on GitHub, then add one to your workspace.
Turn on checks for the repository
Open Analyses in your workspace and turn on checks for it. Only a member with write access can, and analyses then run as that member.
Open or update a pull request
The next pull request opened, or the next commit pushed to an open one, gets the check. Drafts are checked once they’re marked ready for review.
What a run does.
The engine answers on your machine, for the branch you have checked out. Cloud answers for a pull request on GitHub, in a run that checks start or that you start by hand. Only a run that checks start adds the check.
A pull request, or you, starts it
With checks on for a repository, a pull request starts a run when it is opened or gets a new commit, as the member who turned checks on. You can also start a run by hand on the Analyses page, with checks on or off. Cloud never posts comments.
Arbor checks with GitHub
It confirms the pull request’s base and head commits and rechecks that you can read the repository.
It checks out the head commit
No build or package scripts run. The checkout is analyzed in a separate worker process with limits on time and memory.
It maps the change
It builds the graph and blast radius with the same open-source engine libraries as the CLI, then adds its own entry-point, dependency and code-pattern checks.
It saves a private report
Only people in your workspace who can see the repository on GitHub can open it. It expires within 90 days.
If checks started it, it adds one check
The “Arbor impact” check on that commit lists the entry points the change reaches, the called functions with no test found, where to start reading, advisories for package versions the pull request added or updated in
Cargo.lock,package-lock.jsonornpm-shrinkwrap.json, and what Arbor couldn’t see. It stays neutral unless a Team rule matches. A run you start by hand ends with the report and adds no check.
What a report holds.
Keeps
- The entry points whose calls lead to the changed functions
- Each changed function’s callers, the tests that call or name it, and a reading order with CODEOWNERS owners
- Known vulnerabilities from OSV in dependencies pinned in Cargo.lock, package-lock.json and npm-shrinkwrap.json, marked by whether the pull request brought them in; other lockfiles, such as yarn.lock and pnpm-lock.yaml, are listed as unchecked
- The result of each rule in the repository’s
.arbor/checks.yml - File paths, symbol names and counts, such as how many symbols changed and how much code sits upstream and downstream of them
Doesn’t keep
- Your source code
- Patches or diff text
- The checkout, which is deleted when the run ends
What it asks of GitHub.
- Sign-in
- Your GitHub profile and email address.
- Repositories
- Connected through Arbor’s GitHub App. Each run gets a fresh token for that one repository, with read-only access to contents, metadata and pull requests. With checks on, Arbor writes its check with a separate token limited to checks on that repository.
- Access checks
- Before a run and every time a report opens, Arbor asks GitHub whether you can still see the repository.
Used the previous Cloud?
The first Cloud was a GitHub App that posted blast-radius comments on pull requests. It closed on September 23, 2026. This Cloud is a new service: sign in again to start a workspace.
Closing the website does not itself delete existing data. For an earlier account, its data, or billing, email support@getarbor.dev with your GitHub username.
Prefer to stay local?
The engine is free, MIT licensed, and needs no account. Install it, index a repository, and compare your branch with main to see what it reaches. Or explore the recorded Python sample first.
Use the engine