Customer data flow
This page documents every place customer data is processed, which sub-processor handles it, the transfer mechanism, and the encryption-at-rest / in-transit posture. Klyrix is an orchestration platform: your RDS workload data never traverses Klyrix infrastructure — it stays on customer-owned hosts.
Architecture summary
┌──────────────────────────────────────────┐
│ Customer browser (admin / end user) │
└──────────────────┬───────────────────────┘
│ TLS 1.2+
┌───────────────────────────────────────┴───────────────────────────────┐
│ Klyrix Backoffice (Vercel — Frankfurt edge) │
│ + Worker (Vercel functions) │
└─┬────────────┬───────────────────┬──────────────┬──────────────┬───────┘
│ │ │ │ │
│TLS │WG mesh + │REST │REST │API
│ │ SSH │ │ │
▼ ▼ ▼ ▼ ▼
┌────────────────┐ ┌─────────────────┐ ┌────────────┐ ┌──────────┐ ┌────────────┐
│ Supabase │ │ Customer-owned │ │ Stripe │ │ Resend │ │ Cloudflare │
│ Postgres │ │ RDS hosts │ │ (EU) │ │ (USA) │ │ (global) │
│ (eu-central-1) │ │ (customer cloud)│ │ Payments │ │ Email │ │ DNS + WAF │
│ │ │ │ │ │ │ │ │ │
│ All persistent │ │ Workload data │ │ Invoice │ │ Tx email │ │ Edge │
│ Klyrix data │ │ NEVER leaves │ │ metadata │ │ delivery │ │ protection │
│ (audit, users, │ │ customer cloud │ │ (no PAN) │ │ │ │ │
│ billing meta) │ │ │ │ │ │ │ │ │
└────────┬───────┘ └─────────────────┘ └────────────┘ └──────────┘ └────────────┘
│
│ Cron (encrypted)
▼
┌────────────────────────┐ ┌─────────────────────────┐
│ Restic offsite backup │ │ Sentry (USA) │
│ S3-compatible │ │ Error monitoring │
│ (customer-chosen) │ │ PII-scrubbed traces │
└────────────────────────┘ └─────────────────────────┘
Detailed flows
| # | Source → Target | Data | Mechanism | Region | Encryption |
|---|---|---|---|---|---|
| F1 | Customer browser (admin) ↓ Klyrix backoffice (Vercel — Frankfurt edge) | Auth credentials, session cookies, admin actions | TLS 1.2+ direct | EU edge | TLS in transit, bcrypt password hash at rest (Supabase Auth) |
| F2 | Klyrix backoffice ↓ Supabase Postgres (eu-central-1, Frankfurt) | All persistent data: users, audit_logs, billing, telemetry | TLS 1.2+ direct (same region) | EU | TLS + AES-256 at rest + RLS row isolation |
| F3 | Klyrix worker (Vercel) ↓ Customer-owned RDS hosts (Contabo / customer cloud) | Orchestration commands (provision, install, lockdown apply) | WireGuard mesh + SSH | Customer-chosen region | WG ChaCha20-Poly1305 + SSH AES-256 |
| F4 | Klyrix backoffice ↓ Stripe (EU — Ireland) | Customer ID, invoice metadata, payment tokens (no PAN) | Stripe Checkout/Portal redirect | EU | TLS + PCI DSS Level 1 (Stripe-side) |
| F5 | Klyrix backoffice ↓ Resend (USA) | Transactional email content + recipient address | REST API over TLS | USA | TLS in transit; SCC + DPF for transfer |
| F6 | Klyrix backoffice/worker ↓ Sentry (USA) | Error stack traces, request metadata (PII-scrubbed) | REST API over TLS | USA | TLS + DPF certified |
| F7 | End user (RDS workload) ↓ Customer-owned RDS host | Customer business data (Klyrix never reads) | RDP via WireGuard tunnel (handshake-gated) | Customer-chosen | WG + RDP TLS |
| F8 | Klyrix worker ↓ Cloudflare (global edge) | DNS resolution, WAF rules, bot management | Cloudflare API + DNS | Global edge | TLS |
| F9 | Cron (Supabase) ↓ Restic offsite backup (S3-compatible — customer-chosen) | Encrypted backups of profile data + DR manifests | Restic over HTTPS | Customer-chosen | AES-256 client-side (Restic) + TLS in transit |
| F10 | Klyrix worker (WireGuard source monitor) ↓ ip-api.com (third-party IP geolocation service) | Public IP address of a WireGuard VPN client connection; the returned location (country, country code, region, city, ISP, organisation, coordinates) is stored with the connection record, cached for 7 days per IP address and shown in the admin console | HTTPS over the public internet to the paid ip-api Pro endpoint, only while the platform's ip-api API key is configured (without the key no lookup is made) | Not yet documented | TLS in transit |
Cross-border transfers
US sub-processors (Resend, Sentry) operate under EU Standard Contractual Clauses (SCCs) + EU-US Data Privacy Framework (DPF). The processing location and transfer basis of ip-api.com (flow F10) are not yet documented and are under legal review. DPA template at /legal/policies/dpa details the transfer impact assessment.
Customer data residency
Klyrix metadata: Supabase eu-central-1 (Frankfurt). Customer workload data: customer-chosen region (Contabo currently spanning DE, US, UK, JP, IN, SG). Backups: customer-chosen S3-compatible target.
Encryption
In transit: TLS 1.2+ on public-network connections, including the location lookup sent to ip-api.com (flow F10). The only exception is internal: the first hop of DVR screen frames and activity data from the RDS server to the upload relay on the farm hub uses plain HTTP without TLS at the application layer and is carried only inside the encrypted WireGuard mesh tunnel. At rest: AES-256 (Supabase + Restic client-side). Network: WireGuard ChaCha20-Poly1305 for mesh; handshake-gated firewall.
What Klyrix never sees
Files on customer RDS hosts, application database contents on customer hosts, end-user browser/desktop content, RDP session video (unless DVR opt-in is enabled per-user by the customer).
Vendor risk assessment kit
Auditors and procurement teams can request our full vendor risk questionnaire response (CAIQ-style), individual sub-processor SOC 2 reports, and the ROPA (GDPR Art. 30) from security@klyrix.com under NDA.
Last reviewed 2026-09-28.