Security at SupaHost

This page describes how SupaHost protects the infrastructure your projects run on. It's written to be specific, including about what isn't in place yet, so you can judge whether SupaHost fits your app. The security of your app itself, such as Row Level Security and how you handle keys, is yours; see Shared responsibility.

The short version

• Every customer gets their own VM. Nothing is shared with other customers' instances.
• Each project has its own database, JWT secret and keys.
• From the internet, only HTTPS is open. Postgres listens only on the VM's localhost.
• SSH exists only on Business and Enterprise, and only while you've added a key.
• Containers on the VM can't reach the cloud metadata server.
• Backups go to a private bucket in your instance's region.
• SupaHost is in public beta. There is no SOC 2, no ISO 27001, no HIPAA and no SLA.

Isolation

Between customers, the boundary is the VM. Each instance is a separate cloud virtual machine running its own copy of the Supabase stack. No other SupaHost customer's databases, files or services run on your VM. (Like any cloud VM, it runs on the cloud provider's physical servers.)

Between your own projects, the boundary is the database and the keys. Projects on the same instance share one Postgres server, but each project has:

• its own Postgres database,
• its own JWT secret, so a token from one project is rejected by every other,
• its own anon and service_role keys,
• its own Auth, Data API and Storage services, and its own Storage folder,
• its own tenant on the shared Realtime service.

Because they share a server, projects on one instance also share CPU, memory and the 400-connection limit. They also share one postgres database role and its password, so anyone with that password (for example through the SSH tunnel on Business) can connect to every project's database on the instance. Project keys are what separate projects at the API level. If you need two apps fully separated, for example production and an untrusted test environment, put them on separate instances.

Network

• Public traffic is HTTPS only. A gateway (Caddy) terminates TLS and routes each request to the right project's service. Requests without an API key are rejected with a 401 on most paths.
• Postgres is bound to 127.0.0.1. It isn't reachable from the internet on any plan. On Business and Enterprise you can reach it through an SSH tunnel; see SSH access and direct Postgres.
• SSH (port 22) opens only on Business and Enterprise, and only while at least one SSH key is added. The SSH user, supahost, has no password, no root and no Docker access, can run four SupaHost commands with sudo, and can forward ports only to Postgres on localhost.
• No metadata access. Containers and the SSH user are blocked from the cloud metadata server, so code running in an Edge Function or a compromised service can't pick up the VM's cloud credentials.
• Shielded VM. Instances run as Shielded VMs with secure boot and a virtual TPM, on Ubuntu 24.04 LTS, with deletion protection turned on.

Access to your projects

• The dashboard is behind your SupaHost login. New sign-ins send a security email, and Log out everywhere in Settings ends all sessions.
• Studio is reached only through the dashboard, by the owner. Opening it creates a one-minute, single-use signed link; the Studio session then lasts 12 hours and covers one project.
• Team members can view but not change anything. Every write, including opening Studio and revealing the service_role key, is owner-only, and enforced on the server. See Team members.
• MCP access tokens are stored only as a SHA-256 hash, shown once, can be limited to one project and to read-only, and can be revoked at any time. See Access tokens.

Secrets

• Each project's JWT secret and keys are stored in Google Cloud Secret Manager.
• OAuth client secrets and Edge Function secrets are stored in Vault and never shown again after you save them.
• Credentials for an import from Supabase Cloud are passed to your instance as a secret only that VM can read, and deleted when the import ends.

More on handling your own keys in Keeping keys safe.

TLS

Every project API is served over HTTPS at https://<project>.<instance>.supahost.space. Custom domains get certificates from Let's Encrypt automatically, renewed for you. See Custom domains.

Backups

Daily base backups and continuous WAL archives go to a private bucket that belongs to your instance, in the same region as the instance. A restore is rebuilt in a throwaway container with no network access before it's swapped in. See Backups.

Updates

SupaHost ships updated Supabase components as releases. You can apply them straight away with Upgrade now, which snapshots the disk first, or let them install automatically in your maintenance window (03:00-05:00 UTC on the days you choose). See Instances.

What's not in place

Be clear-eyed about these before you put sensitive data on SupaHost:

If your customers or regulators require any of these, SupaHost isn't the right host for that workload today.

Reporting a security issue

Email [email protected] with the details and steps to reproduce. Please don't post vulnerabilities publicly before we've had a chance to respond.

Related

• Shared responsibility
• Production checklist
• Data protection and privacy