# Data protection and privacy

> Who runs SupaHost, where your project data and backups are stored, which services handle emails and billing, and how to export or delete your users' data on request.

Source: https://supahost.app/docs/security/data-protection · Updated 2026-11-11

This page covers who is responsible for SupaHost, where the data in your projects is kept, what passes through other services, and how you can answer your own users' requests to see or delete their data.

## Who runs SupaHost

SupaHost is run by **Volods LTD**, a company registered in England and Wales. It isn't affiliated with Supabase Inc. For anything about data protection, contact **supahost@volods.com**.

## Your data stays in your region

When you create an instance you choose its region: US Central, US West, US East, Belgium, London, Frankfurt, Singapore, Sydney or Tokyo. Your project data stays there:

| Data | Where it lives |
|---|---|
| Databases (tables, Auth users, Storage metadata) | On your instance's disk, in your region |
| Storage files | On your instance's disk, in your region |
| Daily backups and WAL for point-in-time recovery | A private bucket in the same region |

The region can't be changed after the instance is created, so choose with your users' expectations in mind. For UK or EU customers that usually means London, Belgium or Frankfurt. See [Regions](/docs/platform/regions).

## What passes through other services

Some data necessarily leaves the instance to make the service work. To be specific:

- **Auth emails.** Confirmation, magic link, password reset, invite and change-email messages are sent through SupaHost's email delivery provider (Resend), from `noreply@supahost.app`. That means the recipient's address and the message content pass through it. Custom SMTP isn't available.
- **Edge Function source code** is stored by SupaHost's platform so it can be built and redeployed, in addition to running on your instance.
- **Secrets.** Project keys are held in Google Cloud Secret Manager; OAuth client secrets and function secrets are held in Vault.
- **Your SupaHost account** (your name, email and sign-in details) and **billing** are handled by SupaHost's control plane and by Stripe, the payment processor. Card details are entered with Stripe, through **Manage billing**.
- **Infrastructure.** Instances run on Google Cloud virtual machines.

Apart from Auth emails, SupaHost doesn't send your app's end-user data in tables and Storage anywhere else. What you choose to send is up to you: query results returned to an AI agent you connect over MCP, for example, or exports you download.

## Certifications and agreements

SupaHost is in public beta. It doesn't hold SOC 2, ISO 27001 or HIPAA certifications, and it doesn't have an SLA. Don't use it to store protected health information.

If your organisation needs a data processing agreement or has specific questions for a vendor review, ask us at supahost@volods.com.

## Your responsibilities for your users' data

You decide what your app collects and how long you keep it. Two requests come up often, and both can be handled with standard Supabase tools.

### Exporting one user's data

Gather what you hold about a user with SQL in Studio. For a bookings app:

```sql
-- Replace with the user's id from Auth → Users in Studio
with u as (select '6f1c2a9e-4b7d-4c1a-9e3f-2d8b5a7c0e11'::uuid as id)
select json_build_object(
  'account',  (select json_build_object('email', email, 'created_at', created_at)
               from auth.users where id = (select id from u)),
  'profile',  (select row_to_json(p) from public.profiles p where p.id = (select id from u)),
  'bookings', (select coalesce(json_agg(b), '[]'::json) from public.bookings b
               where b.guest_id = (select id from u))
) as export;
```

Include any Storage files the user uploaded. If you keep each user's files in a folder named after their id, list them with `supabase.storage.from('avatars').list(userId)` from a server using the service_role key.

### Deleting a user

Delete the Auth user from a server with the admin API:

```ts
const { error } = await supabaseAdmin.auth.admin.deleteUser(userId)
```

Make sure your own tables follow along. A foreign key with `on delete cascade` removes rows tied to the user:

```sql
alter table public.profiles
  drop constraint profiles_id_fkey,
  add constraint profiles_id_fkey
    foreign key (id) references auth.users (id) on delete cascade;
```

Remove their Storage files too, with `supabase.storage.from('avatars').remove([...paths])`. Use the Storage API for this rather than SQL: direct `delete` statements on `storage.objects` are blocked by a trigger, because removing the row alone would leave the file behind.

Remember that deleted data still exists in backups until they age out: 7 days on Builder and Pro, 14 days on Business. See [Backups](/docs/platform/backups).

## Deleting your own data at SupaHost

- **A project:** **Settings → Danger zone → Delete project**. This stops the project and archives its database.
- **An instance:** **Terminate** on the Instance page sends a termination request.
- **Your account:** **Delete account** in Settings is a request that you confirm by email.

For questions about how deleted data is handled, or for any other data protection request, email supahost@volods.com.

## Related

- [Where is my data stored?](/kb/data-location)
- [Security at SupaHost](/docs/security/overview)
- [Managing users (admin API)](/docs/auth/user-management)
- [Moving off SupaHost](/docs/platform/leaving-supahost)