Security you can actually verify
Where your data lives, how we encrypt and isolate it, how we recover from failures, and the honest status of our certifications.
Data location
Where your data physically lives
| What | Where | Provider | Notes |
|---|---|---|---|
| Databases, Storage files, backups and WAL archive | Warsaw, Poland | Microsoft Azure — Poland Central | default region (pl-waw-1) |
| Databases, files and backups for projects in the Stockholm region | Stockholm, Sweden | Microsoft Azure — Sweden Central | eu-north-1 region, chosen when creating a project |
| Dashboard, accounts, billing, Management API and MCP | Stockholm, Sweden | Amazon Web Services — eu-north-1 | control plane; no data from your databases |
| DNS (platform domain zone) | Global (anycast) | Cloudflare | name resolution only — database traffic doesn't pass through Cloudflare |
Controls
How we protect the platform
Encryption
- TLS 1.2+ for the API, dashboard and Postgres — database connections are TLS-only (SNI routing), including libpq 17 (ALPN).
- Database server disks encrypted by the cloud provider (Azure managed disks, AES-256).
- Database passwords, JWT secrets, service_role keys and function secrets in the dashboard: AES-256-GCM.
Project isolation
- Every project is a separate Supabase stack: its own database, container network, JWT secret and credentials.
- CPU and RAM limits per instance — one project can't starve the others.
- Database servers accept management commands only from the dashboard's address (allowlist + token).
Backups and recovery
- Daily backups (last 7 kept) and on-demand backups, downloadable as a pg_dump file.
- Point-in-time recovery: WAL archive + base backups, restore to any moment within the retention window.
- Restore from the dashboard, API and MCP — with confirmation and an audit log entry.
Access control
- Organization roles: owner, admin, developer, read-only.
- MFA (TOTP + recovery codes) for dashboard accounts and an org-wide “require MFA” policy.
- Personal API tokens with instant revocation; review and close active sessions.
Audit logs
- Sign-ins (successful, failed, lockouts), MFA, password and session changes.
- Operations on projects, plans, backups and organization members.
- Stack service logs and the API request log; export via Log Drains (HTTP, Loki, Datadog).
Monitoring and alerts
- Sampling every 60 s: CPU, RAM, disk, connections, API errors and latency for every project and server.
- Alerts in the dashboard and your channels (Slack, Discord, webhook) with resize suggestions.
- Brute-force protection: rate limits on sign-in and MFA verification attempts.
Compliance
Certification status — no spin
We only show what we actually have. We don't use logos for certifications we haven't earned yet.
RODO / GDPR
Data stays in the EU, with no database transfers outside the EEA. Data processing agreement (DPA) on request, under Polish law.
SOC 2 Type I
We've implemented the controls required by the Trust Services Criteria (access, logging, change management, backups, monitoring). The external audit hasn't happened yet — we don't have a report.
SOC 2 Type II
Requires a multi-month observation period after the Type I audit. We'll share the report with customers under NDA once we have it.
ISO/IEC 27001
We plan to certify our information security management system after SOC 2.
Subprocessors
Who processes data on our behalf
| Entity | Purpose | Location |
|---|---|---|
| Microsoft Azure | Hosting databases, files and backups (data plane) | Poland, Germany |
| Amazon Web Services | Hosting the dashboard and management API (control plane) | Sweden (eu-north-1) |
| Cloudflare | DNS for the platform domain | Global (anycast) |
| Stripe | Card payments — when enabled for your organization | EU / USA (SCCs) |
Customers with a DPA are notified of changes to this list in advance.
Incident response
- Server and project monitoring alerts run around the clock and go to the platform team.
- We report personal data breaches to controllers without undue delay — so they can meet the 72-hour deadline of GDPR Art. 33.
- Current service health: status; a summary after every incident in the changelog.
Reporting vulnerabilities
E-mail kontakt@ulewicz.space with the subject “Security” (details in security.txt). We acknowledge reports within 2 business days. Please disclose responsibly and never test against other customers' data.
Shared responsibility model
We're responsible for the security of the infrastructure, network, operating system and platform services. You're responsible for your project's configuration: Row Level Security policies, keeping the service_role key on the server only, MFA and team member access. Start with the RLS checklist and enable MFA on your account.
Documents
- Privacy policy
- Terms of service
- Data processing agreement (DPA) — on request via the contact form
- SOC 2 report — once the audit is complete, for customers under NDA
Need a vendor security questionnaire filled in (CAIQ, your own spreadsheet)? Get in touch — we answer honestly, including the questions where the answer is “not yet”.