A few ground rules.

What these terms cover#

In shortThe website, the waitlist, Cloud accounts and how the MIT-licensed engine fits in.

These terms cover the getarbor.dev website and its signup lists (the Arbor Cloud waitlist and the list for fix pull requests), and explain how the open-source engine fits in. The engine itself is governed only by its MIT License.

They also cover Arbor Cloud accounts. The “Cloud accounts” part applies when you sign in to Cloud.

The previous Cloud dashboard and account flows closed on September 23, 2026. These terms do not change the terms of that earlier service. For a question about an earlier account or its data, email support@getarbor.dev.

Using the website#

In shortUse it lawfully, don't work around its limits, and report security issues privately.

Use the website lawfully. Do not send spam, interfere with the site, or work around its abuse limits.

The public pages are open, including the engine docs and the sample explorer, and so are Cloud sign-in and the Cloud workspace. The Cloud accounts part below covers using them.

To report a security issue, email support@getarbor.dev with “Security report” in the subject, as our Security page describes. Test locally or in an environment we have explicitly authorized, not the live site. Do not submit live waitlist entries, change production data or try to reach other people's data.

The sample on /explore is an authored Python example, recorded with a local engine build that included unreleased repairs. It shows static call relationships for that example only. It does not scan your code or promise the same results for your repository.

The waitlist#

In shortFree, one entry per address, and no guaranteed invitation. Leave by email.

Joining is free. Use an email address that belongs to you. We use it only to email you about the list you joined: Cloud access, or fix pull requests for retiring AI models. Joining does not create an account, connect a repository, reserve a plan or take a payment.

The form limits repeated signup attempts from one network address, and we may remove abusive signups. Each address is stored once, whatever its letter case, so submitting it again for the same list changes nothing.

A signup does not guarantee an invitation, a place in a queue, a launch date, a price or a feature. To leave a list, email support@getarbor.dev from the address you joined with and say which one; if you don't say, we remove your address from both. Our Privacy notice explains what the waitlist stores.

The open-source engine#

In shortMIT-licensed and provided as is. These terms don't add to that license or narrow it.

The Arbor engine is the CLI and MCP bridge you install and run yourself. It is released under the MIT License, “Copyright (c) 2024 Arbor Contributors”. That license alone governs your use of the engine's code. These terms do not add to it or narrow it.

As the MIT License states, the engine is provided “as is”, without warranty. It needs no Arbor account and makes no calls to Arbor-run services.

Some engine commands write files. “arbor setup” creates an .arbor folder in your project. “arbor hook claude” writes to CLAUDE.md and .claude/settings.json in your project, or in your home folder with --global. If you use receipts, .arbor also holds the text of your prompts. Add .arbor/ to your .gitignore, as the quickstart explains, and check these files before you commit or push them.

Your MCP client and its model may receive the graph context the bridge returns. By default, the GitHub Action in the engine repository posts or updates a comment with its report on your pull request, using the workflow's GitHub token unless you pass another. Set comment-on-pr to false to turn this off. Those tools and GitHub handle that data under their own terms.

Signing in#

In shortYou sign in with GitHub, and your Arbor account follows your GitHub account.

You sign in with GitHub. Arbor requests only the read:user and user:email scopes, and your Arbor account is tied to your numeric GitHub user ID. A sign-in session ends when you sign out, or after 30 days without use.

Anyone who controls your GitHub account can use your Arbor account, so keep that account secure. If you think someone else has used it, email support@getarbor.dev.

Connecting repositories#

In shortConnect only repositories you may share. Access is read-only, per repository, and rechecked on every read.

Arbor reads repositories through the Arbor GitHub App, which you or your organization install on GitHub. Connect only github.com repositories that you may read and are allowed to share with a service like Arbor.

For each run, and each time a report is opened, Arbor asks GitHub for a new token limited to that one repository, with read-only access to its contents, metadata and pull requests. Arbor keeps these tokens in memory and does not save them. Arbor also checks with GitHub that you can still read the repository before a run starts, before its report is saved and each time you open a report. With checks on, Arbor also asks GitHub for a token limited to checks on that repository, to write its own check.

If the GitHub App is uninstalled or suspended, or a repository is removed from it, Arbor stops analyzing that repository and its saved reports can no longer be opened. If you lose access to a repository on GitHub, you can no longer run analyses on it or open its reports. You manage the App in your GitHub settings.

Limits and fair use#

In shortRuns have limits. Don't connect code you can't share, and don't game the trial.

Each analysis runs in its own process, with limits on running time, CPU time and memory. Pull requests too big for GitHub's comparison, and checkouts over our size limits, are refused. Within those limits, source files beyond the number we analyze, or larger than we parse, are skipped, and the report says its graph is partial. We haven't published the exact limits yet, and they may change.

Cloud also limits how often each signed-in user can make requests, and refuses requests above that limit until it refills.

Do not connect repositories you have no right to share, or try to read another workspace's reports. Do not work around the trial allowance, plan limits or seat counts, and do not create extra GitHub accounts to get more trial analyses. Do not submit repositories built to attack or escape the analysis process, and do not use Cloud to break the law or GitHub's terms.

Your code and reports#

In shortYour code stays yours. Reports hold no source code and expire within 90 days.

Arbor claims no ownership of your code. When you start a run, you let Arbor fetch the repository and pull request you chose, analyze them and store the resulting report. Arbor uses them to run the analysis and to show the result to you and to the people your workspace and GitHub allow.

Arbor makes a shallow copy of the repository in a temporary folder, builds its graph from the pull request's head commit and deletes the folder after the run. A report holds the pull request number, branch names and commit IDs, file paths, symbol and entry-point names, call relationships, risk scores and dependency findings. It does not hold your source text or the pull request's diff.

To check dependencies, Arbor sends the package names, versions and ecosystems listed in Cargo.lock and npm lockfiles to OSV (api.osv.dev). That includes the names of any private packages listed there. Cloud analysis does not send your code or reports to a language model.

Reports expire. The retention period is fixed when a run is accepted and is never more than 90 days. It counts from when the report is saved, and a later plan change does not move it. Once it passes, the report can no longer be opened and is deleted. A JSON copy you downloaded stays with you.

What a report can tell you#

In shortStatic relationships worth checking, never proof that a change is safe.

A report describes static relationships in your code: what calls the changed functions, how far that reach extends and which entry points lead to them. It also lists Rust and npm dependencies, from Cargo.lock and npm lockfiles, that have vulnerabilities recorded in OSV. It is not proof that a change is safe, correct or secure.

Static analysis has gaps. Runtime imports and reflection may not resolve, and files that fail to parse are skipped. The graph is built from the head commit, so code that a change deletes or renames is missing from it. Impact can also be overcounted. Each report lists the gaps Arbor detected in its run, but it cannot list every call Arbor failed to resolve.

Treat a report as one input alongside your own tests and review. You decide what to merge and ship.

Workspaces and members#

In shortRoles decide who connects, runs and reads, and GitHub permission is checked every time.

Each account starts with a workspace called “My workspace”. Owners and admins connect repositories, members run analyses, and viewers read reports.

Owners and admins decide who is invited, and admins can invite members and viewers. An invitation goes to one specific GitHub account and appears in that person's Arbor inbox. No invitation email is sent, and invitations expire after 7 days.

Members can see each other's GitHub username, numeric GitHub ID and role, and the workspace's recent invitations.

Membership does not grant repository access. Each person's own GitHub permission is checked every time they open a report.

Trial and paid plans#

In shortA trial counted in pull requests, and paid plans through Razorpay, shown in full before you pay.

The trial is a lifetime number of pull requests analyzed; new commits on a pull request already analyzed don't use more. It belongs to the GitHub account that created the workspace and is shared across every workspace that account creates. Creating another workspace or letting reports expire does not add more. Failed, canceled and unsupported runs, and runs with incomplete evidence, do not use it. Your account shows how many remain.

The plan review shows the price, currency and billing period before you pay. It also explains that the first charge may be immediate and that billing recurs. Only a workspace owner can start or stop a subscription. Razorpay handles payment in its own checkout window, and Arbor never receives your full card number.

Stopping renewal asks the payment provider to cancel the subscription at once. A charge already in progress may still go through. If it does, email support@getarbor.dev. The plan continues until the end of the period you already paid for. Stopping does not by itself issue a refund.

If a payment is refunded or disputed, paid access for that period ends immediately. It is not restored automatically, even if a dispute later closes in your favor.

When a paid plan that includes other members ends, members other than the owner lose access. Work already accepted can finish.

Prices and plan limits are listed on the pricing page and shown again before you buy. The Refund and cancellation page at /refund summarizes how renewal, stopping and refunds work.

Suspension and deletion#

In shortWe can limit accounts that break these terms. You can delete yours by email.

We may limit, suspend or close a Cloud account or workspace that breaks these terms, puts other people's code or data at risk, or harms the service.

To delete your Cloud account, email support@getarbor.dev. Deletion is refused while you own a workspace that has other members, or while a subscription on a workspace you own has not been confirmed as stopped.

Deletion removes your Arbor user record, your workspace memberships, your personal settings and your repository access records, and it revokes pending invitations to you. Workspaces you own are archived, their runs that have not finished are canceled, and their reports expire on schedule.

Some records keep your numeric GitHub ID after deletion: run history, trial usage, invitation history, the membership audit log, billing records, the archived workspaces you owned with their names, and a record of the deletion itself. Invitation history also keeps your GitHub username. Shared views and reviews you created stay until their reports expire. These records stop trial and billing limits from resetting and keep membership changes traceable.

Deleting your Arbor account does not uninstall the GitHub App or remove Arbor's sign-in authorization on GitHub. Remove both in your GitHub settings.

Availability#

In shortNo uptime promise and no certification claimed.

We make no uptime or service-level commitment. Arbor holds no security certification and has not had an independent audit.

We may change, interrupt or discontinue the website, the waitlist or Cloud.

Nothing in these terms limits rights or protections that cannot be excluded under the law that applies to you.

Changes and contact#

In shortUpdated terms appear here with a new date.

The date above identifies this version. Updated terms will appear on this page.

Questions about these terms, the waitlist or the engine go to support@getarbor.dev. For a security issue, put “Security report” in the subject line.