Trust

How DomainsPulse is built

Effective: 2026-04-30

We sell a security-adjacent product, so we publish how we operate. If you're an agency owner doing diligence, this page is for you.

01What we read about your domains

Only public data. Specifically:

  • TLS handshake on port 443 — same as a browser load. We read the certificate the server hands us.
  • WHOIS queries to registry / registrar servers. Public.
  • DNS resolution against your authoritative servers via the system resolver. Public.
  • HTTP GET / with a labelled User-Agent (DomainsPulse-Monitor/1.0). One request per check window.

We do not authenticate, scrape page contents, bypass rate limits, or hit anything that isn't already exposed to the open internet.

02Authentication

  • Email + password authentication via Supabase Auth. Passwords hashed with bcrypt.
  • Sessions are HTTP-only cookies, scoped to the app domain.
  • Row-level security in Postgres enforces that one tenant cannot read another's domains, checks, or alerts.

03Encryption

  • TLS 1.2+ on every request (Vercel-managed certificates).
  • Encryption at rest for all stored data (Supabase / Vercel defaults).
  • Stripe handles all card data; we never see PANs.

04Secrets

Service-role keys, Stripe secrets, and webhook signing secrets are stored as encrypted environment variables and only readable from server-only code paths (cron route, Stripe webhook handler, internal endpoints). Application code that runs in the browser only ever sees the public anonymous Supabase key.

05Alert routing

Alerts can be routed via your own SMTP, your own Slack workspace, your own n8n instance, or any HTTPS webhook you control. We strongly recommend routing through n8n on your own infrastructure if you handle multiple clients — it gives you a single point of audit for outbound notifications.

06Reporting a vulnerability

Email security@domainspulse.app. We respond within one business day, do not pursue legal action against good-faith researchers, and credit reporters publicly with permission.

07Roadmap

  • SSO (Google, GitHub) — Q3 2026
  • SOC 2 Type I — when we cross 100 paying customers
  • Public status page with historical uptime — Q3 2026
  • Per-tenant audit log export (CSV) — Q3 2026