Why local-first - SiteCMD Docs

SiteCMD is a desktop app with a standalone CLI. By default, desktop scans, findings, and project history live on your machine. CLI audits stay on the machine or CI runner that starts them. SiteCMD's connected service stores operational data only for sites you explicitly connect; it is not a mirror of the local database or source checkout.

This is a deliberate choice with real tradeoffs. Most "site health" tools are SaaS. Most of the obvious ones to compare us against are SaaS. We picked the harder path on purpose, and this page explains why.

If you want the operational specifics (which network requests we make, where data lives on disk, etc.), see Privacy & data.

The thinking

When you scan your website, what comes back is essentially a map of everything wrong with it. Misconfigured headers. Exposed secrets. Auth gaps. Database mistakes. Dependency CVEs. Performance problems. Accessibility failures.

That's an extremely sensitive document. It's the recipe for breaking your site.

The standard playbook for site-health tools is to store that recipe in their cloud. Your scans live in their dashboard. Your findings get indexed for search, fed into their analytics, sometimes used as case-study material. The data is technically yours, but it lives on someone else's machine.

SiteCMD works completely without an account. Sending findings to its connected service is something you turn on per site. Sharing exports or connecting an AI editor are separate choices with their own data boundaries.

What local-first means in practice

Your scan results stay on your machine by default. SiteCMD does not upload what your site is doing wrong unless you connect that site, which is a thing you set up deliberately and which sends findings and nothing that resolves to a file. See Connected sites.
SiteCMD does not upload your source code. Code Scan reads the checkout on its execution host: your device for the desktop app, or the machine or CI runner that starts the CLI. Connected submissions contain privacy-preserving finding identities, not source files, raw paths, or line numbers. CI reports and annotations you choose to publish are handled by your CI provider.
Local project configuration stays on your machine. Project names, environment lists, desktop integration credentials, and history remain local. A connected site's URL and the connected automation settings you explicitly configure are stored by the service. Connected Vercel or Netlify credentials are the documented exception to local credential storage.
Your agent fix briefs are built locally. The desktop constructs each brief and serves it through local MCP. It does not pass through SiteCMD's service. Your configured editor can read all projects in the local database and may send returned findings or source excerpts to its model provider under its own settings.

What this isn't

Local-first isn't the same as "offline" or "air-gapped" or "no network." SiteCMD makes a few specific outbound requests on purpose:

Live-site scans hit your URL (that's the job).
Integrations talk directly to the third-party APIs you connected (Google, GitHub, Cloudflare, etc.). They don't route through us.
The separate Updates workflow checks public registries and advisory services for package versions. It sends package names and versions, never your source. Code Scan itself does not make those requests.
License validation confirms an existing subscription or connected-service/catalog credential is still valid. It does not control local feature depth.
Update checks poll for new versions of the app.
Optional telemetry only runs after you opt in from the desktop app. Usage analytics and crash/error reports are separate controls.
A connected site sends that site's findings to SiteCMD, once you connect it. It is the one request in this list that carries anything about what your site is doing wrong, and the one you have to turn on yourself.
Connected CI commands contact the connected service from the runner. Trusted GitHub Actions submissions also request a short-lived workload identity from GitHub's runner-provided OIDC endpoint.

Connected finding submissions exclude source code, raw project paths, credentials, raw logs, and page content. Findings from an unconnected site are not sent to the connected service. Credentials used for activation, connected CI, and explicitly configured hosted deployment providers follow the separate flows documented in Privacy & data.

For the specifics on each of those, see Privacy & data.

The tradeoffs

We picked local-first for the reasons above, but it costs us things real SaaS products get for free:

No team sync without explicit sharing. If you and a coworker both run SiteCMD on the same project, your local databases don't merge. You can share report exports, but there's no "shared SiteCMD dashboard" model.
No multi-device access by default. Your laptop has your scan history. Your desktop doesn't. If you need both to know, you push findings into an external tracker.
Harder support. We can't see your data, so we can't diagnose problems by looking at your account. Logs and reproductions are in your hands.
The local workbench needs the desktop app. Connected report links open in a browser, but local triage and project history remain in the desktop workbench.
Continuous operation is opt-in. The free local workbench stops doing work when the machine is unavailable. The connected service is the explicit hosted path for deploy watches, scheduled scans, shared baselines, and alerts while your laptop is closed.

These are real costs. We don't paper over them. If you'd rather have a SaaS-flavored site-health tool, there are several good ones. SiteCMD is the one for people who specifically don't want that.

Why a desktop app

The day-to-day work of looking at findings, triaging them, understanding what changed since yesterday, exploring correlations between a deploy and a regression, and verifying a fix needs a UI: filters, charts, comparisons, an event timeline, and a path from a finding to a fix.

That is why the current product is a desktop app. The local SQLite database is the source of truth for the app and its bundled MCP server, so your desktop workflow and AI editor see the same evidence without a hosted SiteCMD account.

The shape of the company we want to be

The business model has to match this. The complete local workbench is free. The commercial product is the connected service: hosted operation around production sites after deploys and between local sessions. We don't sell access to your local data. We don't sell ads against your projects. We don't sell aggregated insights to your competitors.

Connected workflows stay bounded to each site you explicitly connect. They send the documented finding contract and operational identifiers needed for hosted execution; they do not quietly mirror your local database or source repository.

This is the explicit version of a promise. The implementation is in Privacy & data.