Skip to main content
Cloud scans check a GitHub repository even when nobody has it open in an editor. Connect a repository and choose when to scan it, such as after a change reaches the main branch. Each report records the exact version of the code it checked.
Choose repositories, scan their source without running it, then discard the source and keep the report.Choose repositories, scan their source without running it, then discard the source and keep the report.

The source is temporary; the scan report is retained.

​
What it checks

A cloud scan runs the same analysis as the editor and the CLI: health score, findings by severity, file coverage, and the dependency and CVE report. Nothing is scored differently because it ran in the cloud. What differs is where the result lives. Every audit is stored against its commit SHA, so a report is a statement about one revision rather than about “now”. Each completed project report also has a Code Map tab. It shows the repository tree and the per-file scores from that same commit.
This matters most for pull requests. A PR audit records the PR head, so reviewing a branch never overwrites your default branch’s score. The two live side by side, and each says which commit it describes.

​
What it does not do

Iris Code never runs your code. A cloud scan downloads a source tarball, expands it, reads the files, and parses your dependency manifests. There is no clone, no npm install, no build step, and nothing from the repository is executed at any point. The extraction refuses symlinks and hardlinks, and the analysis stage has no network access.

​
How a repository gets connected

You install the Iris Code GitHub App on the repositories you choose. See Connecting GitHub for the permissions it asks for and why. Importing a repository queues one audit immediately, so the project has a score before you have configured anything. That first audit counts against your allowance like any other.

​
What triggers an audit afterwards

Each repository decides for itself. A change landing on your default branch, a pull request update, or both. The two cost very different amounts, and the setting says so rather than presenting them as equivalent switches. See Audit triggers.

​
Reports and retention

Every audit keeps its full report for 400 days. After that the report body is removed and the audit row is kept, so the record of what ran, on which commit, and with what outcome survives, while an old link resolves to an honest “the detail is no longer retained” rather than to nothing. In your account, Audit history brings those audit rows together across every connected repository. It shows the repository, commit, branch, trigger, status, score and timestamp without requiring you to open each project separately. Analytics is the separate screen for recorded signals - workspace scans, gates, blocked pushes, and a row for each completed cloud scan - alongside your health trend. Disconnecting a repository permanently deletes its cloud reports from that account or team. A record of the deletion is kept, nothing on GitHub is changed, and you would need to connect the repository again to run any audit against it.

​
Personal and team repositories are separate

A personal account and a team each have their own connected repositories, their own reports, and their own scan allowance. They never share and never merge. Being seated in a team does not let that team’s allowance audit your own repositories, and your personal subscription does not audit theirs. See Scan allowances.

​
What you need

  • Iris Code Pro, or a seat in a team with an active subscription or trial
  • A GitHub account with permission to install an App on the repository you want audited
If you only want the dashboard score to stay current, leave the defaults alone. Merges are audited, pull requests are not, and that is the cheapest configuration that keeps a project’s score true.