nirva|deploy

🛡 PDPA § 40 · GDPR Art. 28

Sub-processors

The complete list of third parties that touch user data.

Last updated: · Operator: บริษัท เบสท์ อินเวสติเกชั่น จำกัด · Tax ID 0-4055-38000-09-1

DPA status is the literal contract status — not marketing copy. "signed" means we have a counter-signed Data Processing Agreement on file. "pending" means we use the service but haven't signed the standard DPA yet (working through it). "N/A — public infra" means the service is opt-in / not yet enabled.

Per Rule 6 — "aligned" is not "certified", "pending" is not "signed". Whatever this page says is what's actually true today.

Payments

Process user payments + issue tax invoices. Card numbers never reach our servers.

Stripe Thailand

✓ DPA signed
PurposeCard / PromptPay / TrueMoney payment processing + Customer Portal
Data sharedEmail, name, billing address, billing country, amount, tax ID (corporate)
RegionUS (data) · Singapore (processing)

PCI DSS Level 1 — our scope is SAQ-A merchant (cards never touch our DB)

OpenNode

⏳ DPA pending
PurposeBitcoin on-chain + Lightning Network payments
Data sharedEmail, amount, Bitcoin address, Lightning invoice metadata
RegionUS

Transactional email

Send receipts, password resets, cancellation confirmations.

Resend

⏳ DPA pending
PurposeTransactional email delivery (receipts, account events)
Data sharedRecipient email, sender email, message body
RegionUS

Marketing emails are NOT sent through this — there are none today.

Compute + storage

Where the app runs + where the database lives.

Google Cloud Run

✓ DPA signed
PurposeStateless web app hosting (control plane)
Data sharedAll request/response data passes through; no persistent storage at this layer
Regionasia-southeast1 (Singapore)
PurposePrimary database (users, subscriptions, invoices, audit log)
Data sharedAll persistent user data
Regionasia-southeast1 (Singapore)

Encryption at rest (Google-managed keys). CMEK option for Enterprise.

Contabo VPS

⏳ DPA pending
PurposeEngine VPS running Dokploy + customer deployment runtimes (Phase 3+)
Data sharedCustomer app code + environment variables + logs
RegionSingapore

Engine credentials encrypted at rest (AES-256-GCM, lib/crypto.ts).

Backblaze B2

⏳ DPA pending
PurposeOff-site database backup storage
Data sharedEncrypted nightly pg_dump archives (.sql.gz)
RegionUS (us-west-002)

Application-side encrypted before upload — see docs/dr-restore.md.

Identity providers (OAuth)

Only the providers you actively use are queried. Each is enabled per-deployment via env vars.

Google

✓ DPA signed
PurposeOAuth sign-in
Data sharedEmail, name, profile picture, sub-id
RegionUS (global)

LINE Login

⏳ DPA pending
PurposeOAuth sign-in (most common for Thai users)
Data sharedEmail (if openid scope), display name, profile picture, LINE user id
RegionJapan

GitHub

⏳ DPA pending
PurposeOAuth sign-in
Data sharedEmail, name, GitHub username, avatar URL
RegionUS
PurposeOAuth sign-in (optional — only enabled if env vars set)
Data sharedEmail, name (when granted by the user)
RegionUS / EU varies

Disabled on the public deployment unless explicitly enabled.

Operational telemetry

Uptime + errors. PII is stripped at the source — these never see user data.

PurposeUptime monitoring + heartbeats for daily backup cron
Data sharedPublic URL responses only (no auth payloads); IP of our own servers
RegionEU (Czech Republic)
PurposeError tracking (planned — Phase 4+)
Data sharedStack traces with PII scrubbing enabled (no email, no body fields)
RegionUS

Not enabled in production yet — listed for transparency when it lands.

PurposeCookie-free page analytics (planned)
Data sharedPage URL, referrer, browser type — no cookies, no fingerprint, no IP storage
RegionEU (Germany)

Cookie-free by design — does not require a consent banner.

Network + edge

DNS, TLS, DDoS protection. Sees request headers + IPs.

Cloudflare

✓ DPA signed
PurposeDNS, TLS termination, DDoS protection
Data sharedSource IP, request headers, request path (no body inspection unless WAF rule triggers)
RegionGlobal edge (closest PoP)

Your rights regarding sub-processors

Under PDPA § 30 you can request a complete list of who has accessed your data. The narrowest answer is your own audit log; the broadest answer is this page.

You can request data deletion (PDPA § 32) via Settings → Account — we honor the 7-day grace window then anonymize all rows (we don't hard-delete because foreign-key references in invoices must survive for 7-year tax retention).

If you object to a specific sub-processor (e.g. Stripe in the US), the only honest answer today is "you'd need to stop using NirvaDeploy" — we don't have alternate processors per region in Stage 0-1. Enterprise customers (Phase 5 BYOC) get the option to run on their own GCP / Azure / on-prem.

Change log

Every addition or removal of a sub-processor lands here. By signing up you agree to be on the list of users notified by email at least 30 days before a material change (e.g. a new processor added, region change for an existing one).

  • 2026-05-23 — initial publication of this page. Inventory matches the state of process.env.* as of this date.

Questions

Privacy + sub-processor questions: [email protected]

Security disclosure (vulnerabilities): [email protected] — see /security for disclosure timeline.