SiteCMD is a desktop app. Your scans, your findings, your source code, your project history — all of it lives on your machine. There is no SiteCMD backend that holds your data.

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 comprehensive map of what’s 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.

We didn’t want to do that. So we didn’t.

What local-first means in practice

Your scan results stay on your machine. SiteCMD never uploads what your site is doing wrong.
Your source code stays on your machine. The source audit reads files locally, analyzes them locally, and writes results to your local database.
Your project configuration stays on your machine. Project names, URLs, environment lists, integration credentials, history — all local.
Your AI fix prompts are built locally. When SiteCMD generates a prompt for your AI editor to fix an issue, that prompt is constructed on your machine and passed to your editor over MCP (which also runs on your machine). It doesn’t pass through us.

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.
Dependency lookups check public registries (npm, pypi, etc.) for known-bad versions. They send package names and versions, never your source.
License validation confirms your paid-tier license is still valid.
Update checks poll for new versions of the app.

That’s it. No telemetry to us. No analytics ping. No crash reports unless you opt in (a feature we haven’t built yet).

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 integration. If you and a coworker both run SiteCMD on the same project, your local databases don’t merge. You can share via the GitHub Issues / Jira mirroring feature, or via 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.
No browser interface. Some workflows are easier from a browser. We don’t have one.
No “look at your site from anywhere” mode. If you want continuous external monitoring (independent of whether your laptop is open), you need an actual uptime service. SiteCMD has the UptimeRobot integration for exactly this reason.

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 instead of a CLI

We do ship a CLI (covered separately). It runs the same checks. It’s the right tool for CI pipelines, deploy gates, and scripted workflows.

But the day-to-day work of looking at findings, triaging them, understanding what changed since yesterday, exploring correlations between a deploy and a regression — that’s not a CLI workflow. It needs a UI: filters, charts, side-by-side comparisons, the timeline of events for a project, the ability to click through from a finding to a fix.

So the desktop app is the daily driver, the CLI is the automation surface, and the local SQLite database is the shared truth between them. They live on your machine, talk to each other, and never need a remote server to function.

The shape of the company we want to be

The business model has to match this. We sell a desktop app and a paid tier. We don’t sell access to your data. We don’t sell ads against your projects. We don’t sell aggregated insights to your competitors.

If we ever did want to add team or organization features, we’d build them in a way that keeps the local-first promise intact (e.g., explicit sync to a server you control, or peer-to-peer between team members, or push-only integrations into trackers you already use). We won’t quietly mirror your scans to a cloud and call it a feature.

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