Cloud history follows the work you already do. Connect your local project once, or enable summary sync when creating its CI runner key. Full scans and agent rescans through the Saer launcher then save approved numerical summaries automatically. There is no report export or upload step in the normal workflow.
Connect CI once
Create a project in your workspace, choose CI checks and automatic cloud history, then review its summary policy and create the key. Review the fixed field policy once: version, scan source and numerical counts for tokens, drift, components and static accessibility findings. Store the resulting key as the SAER_CI_TOKEN repository secret described in CI setup.
Use the GitHub workflow alongside your existing checks. Each job installs Saer without a browser, scans the checked-out change, updates cloud history from the key's project and reports drift inside the GitHub check. No project ID variable, export, manual upload or separate reporting job is required.
Connect local scans once
From your project folder, use the connection command shown in its cloud workspace. It includes the project ID and asks you to approve automatic summary sync. Your first ordinary full scan will then start the history.
saer cloud connect --project PROJECT_ID
saer scan --fullReplace PROJECT_ID with the ID from your workspace. Connection stores a private policy outside the repository, bound to this local folder. A checked-in project file cannot enable uploads. No credential is stored in the connection policy. From then on, full scans through the Saer launcher sync the approved fields automatically. Agent rescans through saer mcp also update connected history, without an extra command. Free scans stay offline. Unconnected projects remain local.
Keep working if sync is unavailable
A cloud outage does not turn a valid local scan into a failed analysis or a clean CI result. Saer reports that sync is pending and retries queued summaries on the next full scan. Up to 20 summaries are kept locally; retries use stable request IDs to prevent duplicates.
You can explicitly retry with saer cloud sync. This is recovery, not a step required after every scan. Repeated scans with unchanged counts still create separate history entries, while retrying the same upload does not.
Control what leaves the machine
Only the fixed approved summary fields are sent. Source code, paths, component names, token values and full reports are excluded and refused by the summary API. Unknown counts stay unknown. A future expansion of the field policy requires another review.
Run saer cloud disconnect to stop local automatic sync. For CI, revoke the runner key to stop its future access and create a key without automatic history if you only want local job results. Keys are hashed and project-scoped. Beta keys expire within 30 days or the trial. When paid plans open, paid connections will survive renewals while every operation still checks current access. They cannot read history or manage accounts. They are bearer credentials, so keep them out of untrusted fork jobs.
Read history in context
Compare the same scan scope and version. Counts are static observations, not proof of accessibility conformance or a maturity score. A lower count may reflect different coverage. Inspect the source evidence in your local report or agent before making a change.
The beta permits ten projects per account, 1,000 snapshots per project and five active keys per project. The workspace shows the latest 100 snapshots. To request deletion of hosted data, contact hello@saer.app; self-service project deletion is not available yet.
The workspace also offers a collapsed import option for historical summaries. It is optional and not part of ordinary scanning or CI.
See it on your own codebase.
Request early access