This page is the specifics behind Why local-first. What data lives where, what gets sent over the network, and what those requests actually contain.

What stays on your machine

Everything about your projects lives in a single per-user SQLite database, opened in WAL mode for safe concurrent reads and writes, inside SiteCMD’s app-data directory:

macOS: ~/Library/Application Support/com.sitecmd.app/
Windows: %LOCALAPPDATA%\com.sitecmd.app\ (falls back to %APPDATA%)
Linux: $XDG_DATA_HOME/com.sitecmd.app/ (defaults to ~/.local/share/com.sitecmd.app/)

Inside that directory you’ll find:

sitecmd.db — the SQLite database (plus sitecmd.db-wal and sitecmd.db-shm while the app is running)
audit.log — JSONL log of sensitive operations
logs/ — rolling application logs

The database contains:

Scan results. Every check that ran, what it found, severity and confidence, timestamps.
Scan history. Every scan, retained per your prefs (default: 50 most recent per site).
Source-audit findings. When Code Scan runs, results land here. The source files themselves stay where they are; only the findings are persisted.
Project configuration. URLs, environments, linked source folder paths.
Issue state. Snoozes, dismissals, fixes, blocked-with-reason notes.
Integration event data. When you connect an integration (analytics, search console, uptime), the events SiteCMD pulls are stored locally for correlation. The integration’s own data still lives in the integration; SiteCMD doesn’t mirror it wholesale.

What is never on your machine

(Because it never leaves, and we never see it.)

Your scan results. SiteCMD has no “cloud sync” mode. There is no SiteCMD backend that stores your findings.

Your source code. The source audit runs entirely locally. AI fix prompts generated for your editor are built locally and passed over MCP, which also runs on your machine.

Your project configuration. Project names, URLs, environment lists, and history are local-only.

Network requests SiteCMD makes

A handful of outbound requests happen on purpose. Each is narrow and named.

Scans

The live-site engine fetches your URL plus a handful of related URLs (sitemap, /robots.txt, alternate URLs for security headers). Every outbound URL passes through a network policy gate that blocks:

Non-HTTP schemes (only http:// and https:// are allowed)
Cloud metadata endpoints (metadata.google.internal and similar)
Private RFC1918 IPs (10.x, 172.16-31.x, 192.168.x) and other non-routable ranges, including IPv4-mapped IPv6 forms

Localhost and loopback addresses are allowed by default so you can scan your local dev server. The point of the gate is to stop a malicious site from redirecting SiteCMD into your internal network through a 3xx response.

Integrations

When you connect an integration, SiteCMD talks directly to that service’s API using credentials you provide:

Analytics: GA4 (Google), Plausible
Search: Google Search Console, Bing Webmaster
Uptime / Hosting: UptimeRobot, Cloudflare
Source / Deploys: GitHub
Performance: PageSpeed Insights
Issue tracking: GitHub Issues, Jira

These requests go from your machine to the integration’s endpoint. They don’t pass through SiteCMD servers.

Dependency lookups

The source-audit supply-chain stage looks up package versions in public registries (npmjs.org, pypi.org, packagist.org, crates.io, and others). The lookups send package names and versions only. They don’t send your package.json, Cargo.lock, or any other source content.

License validation

If you’re on a paid tier, SiteCMD validates your license against LemonSqueezy (api.lemonsqueezy.com). The request sends your license key and our store ID. We don’t send anything about your projects, scans, or source.

License validation runs at app startup and periodically thereafter. If your machine is offline, SiteCMD enters an offline grace period during which the license remains valid. Beyond the grace period, premium features pause until the next successful validation.

Auto-updates

The desktop app polls releases.sitecmd.com for new versions and downloads the update bundle from there when one’s available. The polling request sends your current version and platform string. It doesn’t send anything about your projects.

Update bundles are cryptographically signed (minisign). The app verifies the signature before installing, so a compromised release server can’t push you a tampered binary.

Crash reports

SiteCMD does not send crash reports anywhere by default. If you opt into sharing diagnostics in the future, that’ll be a separate explicit choice.

Where credentials live

Integration credentials (API keys, OAuth tokens) are stored in your operating system’s credential store, not in the SiteCMD database:

macOS: Keychain
Windows: Credential Manager
Linux: GNOME Keyring, KWallet, or any secret-tool-compatible store

The SQLite database stores references (which integration is connected, when it was last used), but never the secret itself. If someone gets your SiteCMD database file, they can’t extract your tokens from it.

The audit log

Every sensitive operation writes a line to audit.log in your SiteCMD storage directory. JSONL format, one line per operation. Recorded operations include:

License validation calls
OAuth flows (start, success, failure)
Webhook deliveries
Destructive data-admin operations (e.g. project deletion)
Panic events from the Rust backend

The audit log redacts secrets before writing. License keys, OAuth tokens, and webhook secrets are reduced to a key prefix and a hash. Email addresses are reduced to a domain. Hostnames are kept; raw URLs with query strings are not.

You can read the audit log at any time. SiteCMD does not upload it.

Data export

Two ways to get your data out:

CSV exports from the Issues page (filtered or full) for spreadsheet workflows.
Report HTML exports for stakeholder-facing snapshots.

There’s no “export everything to one file” yet. Your SQLite database is the source of truth, and you can back it up directly by copying the storage directory.

Data deletion

To wipe a single project, delete it from Settings → Projects. SiteCMD removes the project’s scan history, findings, integration data, and any associated keychain entries.

To wipe everything, quit SiteCMD and delete the storage directory listed at the top of this page. Integration credentials in the OS keychain are separate; search for “SiteCMD” entries in Keychain Access (macOS), Credential Manager (Windows), or secret-tool (Linux) and remove them.

What we’d do if compelled

Since your data lives on your machine, we don’t have it to hand over. We can’t subpoena what we can’t see. License records (who paid us for what) we do have, and we’d respond to a legitimate request for those the same way any business does. Your scans aren’t part of that.

Reporting a security issue

If you find a security issue in SiteCMD itself, see Security disclosure.