Security

Security at Narvinrests on a few principles: store only what the Service needs, encrypt the sensitive parts, isolate the systems that touch customer sites, and be honest about what we do and don’t yet have. We are a small team; this page lists concrete measures rather than certifications we don’t hold.

• The web application is hosted on Vercel.
• Monitoring workers run in three regions on three continents— Frankfurt, Ashburn (N. Virginia), and Singapore — on Fly.io and Hetzner infrastructure.
• Customer data is stored in Neon-managed PostgreSQL. Internal worker coordination uses Redis over a private network; it is not exposed to the public internet.
• Production access is limited to authorized operators, and secrets are stored in the hosting providers’ secret managers — not in the code repository.

• In transit: all traffic to and within the Service uses TLS.
• At rest: alert-channel credentials (such as webhook URLs, bot tokens, and phone numbers) and third-party integration tokens are encrypted with AES-256-GCM before they are written to the database. Database storage itself is encrypted by our hosting provider.
• Webhooks we send are signed with HMAC so your systems can verify they genuinely came from us; inbound provider webhooks are verified the same way.

• Passwords are never stored in plain text — they are hashed using the scrypt key-derivation function via our authentication layer.
• Sign-in is also available through single-use magic links sent to your email, and new accounts receive a verification email.
• Password-reset flows use time-limited, single-use tokens.

All payments are processed by Paddle, our merchant of record. Card details are entered on and handled by Paddle’s PCI-compliant checkout — we never see or store card numbers. We store only the subscription metadata needed to manage your plan, and billing webhooks from Paddle are signature-verified before we act on them.

Our checks are designed to be safe, light-weight guests on the systems they monitor:

• Uptime probes send ordinary HTTP requests with an identifiable Narvin user agent, measure status and response time, and discard response bodies without storing them.
• Checks run on the schedule you configure, subject to per-plan minimum intervals — they do not hammer your site.
• SSRF protections are enforced on every fetch the platform makes: URLs are resolved and validated so probes cannot be pointed at private networks or internal services, and connections are pinned to the validated address to prevent DNS-rebinding tricks.
• The public instant-check and site-grader tools apply the same SSRF guards and are rate-limited.

Fine-grained monitoring events are retained for 90 days by default, after which they are pruned; incident records are kept longer as service-history evidence. Account and configuration data is retained while your account is open. For your rights over personal data — access, correction, deletion, and export — see our GDPR & Data Protection page and Privacy Policy, or write to support@narvin.io.

We use a small set of providers to run the Service. Each processes data only as needed to provide its function:

• Vercel — web application hosting.
• Fly.io and Hetzner — monitoring worker infrastructure.
• Neon — managed PostgreSQL database.
• Amazon Web Services (SES) — transactional email delivery.
• Cloudflare (R2) — storage of generated report documents.
• Paddle — payments, as merchant of record.
• Anthropic — large-language-model API used to generate AI client reports from your monitoring and analytics data.
• Google — PageSpeed Insights measurements, and the Google Analytics / Search Console APIs when you connect those integrations.
• Meta (WhatsApp Business Platform) — alert and report delivery over WhatsApp, when you enable that channel.

We welcome reports from security researchers. If you believe you have found a vulnerability in Narvin:

• Email security@narvin.io with enough detail to reproduce the issue. We will acknowledge your report and keep you informed as we investigate.
• Please give us reasonable time to fix the issue before any public disclosure, and avoid accessing other customers’ data, degrading the Service, or using automated scanners against production at disruptive volume.
• We do not currently run a paid bug-bounty program, but we credit researchers who report responsibly, if they wish.

Security questions or reports are always welcome: