Privacy Policy

SiteCMD is built local-first. That's not a marketing phrase - it's the architecture. Your source code and integration credentials never leave your machine, and neither do your scan data or project configuration unless you connect a site to the connected service, which is off until you set it up. This policy explains exactly what data exists where.

SiteCMD is operated by Brambleworks LLC, referred to here as "we" and "us", and we are responsible for the limited data this policy describes.

Data that stays on your machine

The following data is stored locally in a SQLite database on your device. None of it is transmitted to us unless you connect that site to the connected service, described underConnected sites below:

• Scan results, scores, and issue history
• Project configurations and URLs
• Score trends and historical data
• Report exports (PDF, CSV)
• Code scan results and source analysis
• Event timeline data
• Scheduled scan configurations

Integration credentials (API keys for Google Analytics, Cloudflare, GitHub, Jira, UptimeRobot, etc.) are stored in your operating system's native keychain (macOS Keychain, Windows Credential Manager), not in the database. We never see these credentials.

Data we collect on this website

Email addresses

If you sign up for launch or release notifications on this website, we store your email address in Cloudflare KV. We use it solely to notify you about SiteCMD releases and product updates. We do not sell, share, or use your email for any other purpose. You can request removal by contacting us.

Contact form submissions

When you submit the contact form, your name, email, subject category, and message are forwarded to our support inbox through Resend, our transactional email provider. We do not store contact submissions on this website beyond what Cloudflare captures in standard request logs. Resend's handling of message contents is governed bytheir privacy policy.

Purchases and billing

Connected-service access is comped during the founder beta, and this website does not offer a public purchase during that measurement window. Lemon Squeezy continues to manage payment methods, renewals, cancellations, and license keys for existing subscribers. We do not store payment details on this website.

Web server logs

This website is served by a Cloudflare Worker. Cloudflare collects standard request logs (IP address, user agent, pages visited) as part of their service. This is governed byCloudflare's privacy policy.

Privacy-friendly analytics

This website uses Plausible Analytics to understand aggregate page views and referrals. Plausible does not use cookies and does not build personal profiles. This marketing website does not use Google Analytics, Facebook Pixel, advertising pixels, fingerprinting, or cross-site tracking. (That is separate from the desktop app's optional, read-only Google Analytics integration, which is described below.)

Data SiteCMD transmits

Connected sites

Connecting a site is the one feature that sends your findings to a SiteCMD server, and it is off until you set it up in Settings. There is no background sync: an installation that never connects a site never contacts connect.sitecmd.com, and one that does contacts it when you sync, not on a timer.

Before each deploy of that server, the pipeline keeps a copy of its database for 30 days in the same Cloudflare account, so a migration that goes wrong can be undone. Nothing else holds a copy.

What a connected site sends is the identity of a finding, not its evidence: the site's URL and the alias you gave it, the check that fired, its severity and confidence, the route on your own site it fired on, timing measurements, the detected framework and version, the engine and check-registry versions the scan ran under, which checks the scan completed, and the commit SHA the code side was observed against. When you first connect, it also sends the issue decisions you already made locally, so a site you have been triaging for months does not arrive as a fresh list of problems.

A code finding travels as a keyed hash of where it fired, computed under a per-project key that stays on your device. That is what lets the service recognise the same finding across two scans without ever holding anything that resolves to a file. Your source code, file paths, file contents, line numbers, page HTML, response bodies, screenshots, dependency lists, and integration credentials have no field in that payload at all. The app shows you the exact object before it sends one.

Connecting a site also lets SiteCMD scan it from our own infrastructure, on a schedule and with the app closed. Those requests leave Cloudflare's network rather than your machine. There is no fixed SiteCMD address to allowlist and none to publish: outbound requests from Cloudflare Workers leave the anycast network, and the source address varies by the location that ran the scan. They identify themselves with the sameSiteCMD/<version> (+https://sitecmd.com/scanner) string a desktop scan sends, and the scanner page explains what is and is not provable about that.

A hosted scan also contacts Cloudflare's public DNS-over-HTTPS resolver (cloudflare-dns.com). It receives each hostname the transport scanner or isolated browser is about to fetch as an A and AAAA lookup so an address in a blocked range is refused before the request. That includes public subresource hosts named by the page. The resolver is not told which account or connected site caused the query. The hosted transport does not read your domain's mail or DNS-policy records and does not query a vulnerability or domain-registration service; those checks are reported as unanswered from that vantage.

The browser-analysis half loads each selected route in a fresh isolated browser context. Like any browser visit, it may request public scripts, stylesheets, images, fonts, and read-only fetches from hosts named by that page. SiteCMD intercepts those requests, fetches each bounded response through Cloudflare Workers public egress, and fulfills it into the browser. Target hosts may see the requested URL, request headers, and any cookies the page set during that isolated load. SiteCMD blocks unsafe request methods, service workers, WebSockets, media streams, downloads, popups, non-web schemes, and targets in blocked address ranges. The context has none of your personal browser cookies or saved sessions and is destroyed after the route is evaluated.

Page bodies, rendered DOM, query strings, screenshots, and browser storage are never written to a SiteCMD store, log, trace, or error report. Only derived verdicts and timing measurements survive the hosted scan.

The SiteCMD CLI uses one site-scoped CI token for exactly four connected operations: reading the deployment ordering cursor, gate, deploy, and connected --submit. The ordering cursor contains only the site's current deployment identity, whether that credential supports GitHub OIDC attestation, and, when the credential owns the site's selected publish authority, that authority's kind, id, epoch, activation time, and current publish sequence. It contains no findings or other account data. gate sends a code-side candidate from the CI runner but stores nothing: it answers which findings are new against the site's baseline and changes nothing about what the site is known to be.deploy records deployment history, while connected --submit records or converges the deployment and its privacy-preserving code findings.

What a connected site sends us is aged out on a schedule, not kept indefinitely: the site's event stream, deployment history, and timing measurements are deleted after 90 days. If you disconnect a site, its remaining state is deleted 30 days later. Request receipts are deleted after 7 days. Erasing a site removes everything at once and leaves only a receipt naming the site identifier and domain, kept for one year so you can prove the erasure happened. A site's current findings and your decisions about them are kept as long as the site stays connected, because they are the baseline the service grades against.

Update checks

SiteCMD periodically checks for application updates by contacting releases.sitecmd.com. This request includes your current app version and operating system platform identifier. No personal data, scan results, or project information is included. We keep an aggregate count of these update checks, and of installer downloads, broken down only by app version and platform, so we can see how many installs are active and how many downloads each release gets. These counts contain no identifier for you or your device.

License activation and validation

When you activate an existing license, SiteCMD sends your license key and a machine-scoped activation identifier to LemonSqueezy's API at api.lemonsqueezy.com. The activation identifier is a SHA-256 hash of your device hostname and username encoded as a 16-character hex string - your raw hostname and username are never transmitted. Ongoing validation requests send your license key and the per-activation instance ID returned at activation. No scan data or project information is included. LemonSqueezy's handling of this data is governed by their privacy policy.

Fix-guide catalog

Eligible connected-service and existing-license entitlements receive maintained guidance as a signed catalog the app downloads in the background. Activating such an entitlement also registers this installation with the catalog service at activation.sitecmd.com, sending your license key, the same per-activation instance ID described above, and a random single-use nonce. The service returns an opaque access token; your license key is never sent again after that exchange. Deactivating the license sends the same identifiers to release this installation.

The app then checks catalog.sitecmd.com about once a day for catalog updates. That request carries only the opaque token, the app version, and the installed catalog version and channel. No scan data, project information, or source ever accompanies either request.

Dependency update checks

The dependency update check queries public package registries for the latest version of each package found in your project: registry.npmjs.org (npm), pypi.org (Python), repo.packagist.org (PHP/Composer), crates.io (Rust), rubygems.org (Ruby), proxy.golang.org (Go), api.wordpress.org (WordPress plugins and core), and updates.drupal.org (Drupal modules). These requests send only the package name in the request URL or as a query parameter. They do not send your lockfiles or any source file content.

SiteCMD also queries the OSV vulnerability database (api.osv.dev) to check for known security advisories. This is a single batched POST request that sends the package names and currently installed versions of packages found in your project. Web scans use the same database to check well-known front-end libraries (jQuery, Bootstrap, and similar) whose names and versions appear in the scanned page's script URLs. No source file content, lockfiles, or credentials are included.

PageSpeed Insights (web performance)

Web Vitals uses Google's PageSpeed Insights service (www.googleapis.com). This call is made on demand from the desktop app, when you open the Web Vitals detail or refresh a project dashboard's performance signals; it does not run on a background schedule. The request sends the URL being measured and the strategy (mobile or desktop). If you add an optional PageSpeed API key under Settings, it is stored in your OS keychain and appended to these requests to raise Google's rate limit; without one the call is made without a key. No scan results, source file content, or project configuration are sent.

Browser analysis during web scans

To measure Core Web Vitals, and to run axe-core when accessibility analysis is on, SiteCMD loads the page in a hidden webview. That window is private: it shares no cookies, storage, or cache with your browser or with earlier scans, it cannot open windows or start downloads, and every top-level navigation it attempts, including redirects and meta refreshes, is re-checked against the same network policy gate, so a public page cannot redirect the analyzer to an internal address.

What that gate does not cover is the page's own subresources. Once the page loads, its images, scripts, stylesheets, fonts, and fetch calls are issued by the platform's web engine, to whatever hosts the page names. SiteCMD does not choose them and the engine gives it no way to intercept them, so those requests are in exactly the position they would be if you opened the page in your own browser. Nothing from them reaches SiteCMD; the measurements are stored locally with the rest of the scan. Worth knowing because scheduled scans run this layer too, so a site that starts serving something hostile does so with nobody watching. If that matters for a particular site, run its scans manually rather than on a schedule.

Domain checks during web scans

The web scan's domain checks look up the scanned site's public DNS records (SPF, DMARC, DKIM, MX, DNSKEY, CAA, and a CNAME/address lookup for the www subdomain) through your machine's own configured DNS resolver, the same resolver every other application on your computer uses. SiteCMD never routes DNS queries to its own or any hardcoded third-party DNS service. To read the domain's public registration expiry date, SiteCMD queries the RDAP redirect service (rdap.org), which forwards to the TLD registry's public RDAP endpoint. These requests contain only the domain name being scanned (and, for the www alias check, the hostname its CNAME record points at).

Optional usage analytics

The desktop app can send anonymous product usage events to telemetry.sitecmd.com, a SiteCMD-controlled Cloudflare Worker, if you opt in. These events help us understand which workflows are used and where scans or app flows fail. They include app version, build channel, operating system family, anonymous install identifier, event name, your subscription tier as a plan name only ("free" for the complete local workbench, or the name of an existing subscription's legacy plan; never a license key or billing details), and small counters such as issue totals by severity. Raw event rows are retained for no more than 90 days before scheduled deletion. Each accepted event also increments a de-identified aggregate counter (event name, app version, build channel, operating system family, architecture, and tier) that carries no install identifier. Because nothing links those counts back to an individual install, a deletion request cannot single them out; they are not retained beyond three months. They do not include scan URLs, website content, source code, local file paths, project names, credentials, license keys, raw logs, request bodies, or integration data.

Optional crash and error reports

SiteCMD sends sanitized frontend errors and failed app-command diagnostics to Sentry (o4511662343127040.ingest.us.sentry.io) only if you opt in through the consent prompt or under Settings → Privacy. Session replay, broad performance tracing, autocapture, and default personal data collection are disabled. Error payloads are scrubbed before sending to remove URLs, filesystem paths, email addresses, secrets, license keys, source snippets, request bodies, and provider responses.

Website scanning

When you scan a URL, SiteCMD makes HTTP requests directly from your machine to the target website. These requests are visible to the website's server in their access logs, like any other browser visit. SiteCMD identifies itself in the User-Agent header. No data from these requests is sent to us.

Third-party integrations

When you connect integrations (GA4, Cloudflare, GitHub, etc.), SiteCMD makes API calls directly from your machine to those services using credentials stored in your OS keychain. The data returned is cached locally. We do not proxy these requests and have no access to the data exchanged.

Google Analytics and Search Console data

When you connect Google Analytics or Google Search Console, SiteCMD uses Google OAuth to request read-only access to your own account data: the Google Analytics read-only scope to display your traffic metrics, and the Search Console read-only scope to display your search performance. These requests are made directly from your machine to Google's APIs, and the returned data is cached locally on your device. SiteCMD's servers never receive, proxy, store, or have access to your Google Analytics or Search Console data, and we never use it for advertising or sell it. You can revoke this access at any time from your Google Account permissions page or by disconnecting the integration in SiteCMD.

SiteCMD's use and transfer of information received from Google APIs to any other app will adhere to the Google API Services User Data Policy, including the Limited Use requirements.

How we protect your data

Because SiteCMD is local-first, the strongest protection for your sensitive data is that it stays on your device: your Google Analytics and Search Console data are never transmitted to, proxied by, or stored on SiteCMD's servers, and neither are your scan results or project configuration unless you connect that site. The specific safeguards are:

• Encryption in transit: all requests to Google's APIs (and every other connected integration) are made over HTTPS/TLS with full certificate validation. SiteCMD does not accept invalid or self-signed certificates on these connections.
• Secure credential storage: Google OAuth access and refresh tokens are kept in your operating system's encrypted credential store (macOS Keychain, Windows Credential Manager, or the Linux Secret Service / libsecret), never in the SiteCMD database and never in plaintext on disk. The database only records that an integration is connected, not the token itself.
• No central copy: data returned from Google is held on your device, in a short-lived in-memory cache and, where needed for correlation, in the local SQLite database. There is no SiteCMD-hosted copy, so there is no central store of your Google data for us to lose or for an attacker to breach.
• Revocation and deletion: disconnecting the integration deletes its OAuth tokens from your operating system's credential store. You can also revoke SiteCMD's access at any time from your Google Account permissions page, and permanently delete all locally stored data by removing SiteCMD's data directory.

Data we never have access to

Whatever you do, and whether or not you connect a site:

• Your source code, file paths, and file contents (code scan runs entirely locally)
• Your integration API keys or tokens
• Your analytics, uptime, or search data
• Page HTML, response bodies, and screenshots from your scans

Unless you connect that site, in which case what we hold is listed under Connected sites above:

• Your scan results or scores
• The websites you scan
• Your project configurations
• Your fix history or dismissed issues

Data export and deletion

You can export your entire database at any time through SiteCMD's Settings page. You can delete all scan history, individual scans, or the entire database. Since data is stored locally, deleting the SiteCMD application and its data directory removes all data permanently.

The desktop app also lets you disable telemetry, delete unsent local telemetry, reset the anonymous telemetry identifier, and request deletion of uploaded SiteCMD-hosted telemetry tied to that anonymous identifier. Sentry diagnostic retention and deletion are governed by Sentry's service controls, and we keep those reports limited to sanitized error data.

Children

SiteCMD is not directed at children under 13. We do not knowingly collect personal information from children.

Changes

We may update this policy. Changes will be posted on this page with an updated date. Material changes will be communicated through the application.

Contact

Privacy questions: contact us.