A dedicated server, not a shared cluster
Each project runs on a dedicated server that belongs to your account and isn’t shared with other customers, so your database never sits on a multi-tenant cluster next to other customers’ rows.
Security
Security that starts with a server of your own.
How Da8a protects your project, in plain terms. This page describes how the product works today; it isn’t a certification or a contract.
No shared root login
Servers we create for you get no emailed root password, and the server agent locks the root account. Day-to-day changes go through the dashboard, which checks your permission on the server for every action.
A narrowly scoped server agent
The agent on your server holds a token scoped to that one server, runs only the containers assigned to it, and refuses configurations that would escape their container. It doesn’t update itself from the network: new versions are signed releases checked against a key pinned when the server is set up.
Keys stay where they belong
The anon key is safe in browsers when Row Level Security is on. Secret keys sit behind a Reveal button and are shown only to people with the credentials permission. Platform keys never go onto customer servers.
Row Level Security
Every request through the REST API, Realtime and Storage is checked against your Postgres Row Level Security policies, written in SQL next to your data.
Write-only secrets
Edge function secrets are stored on your server and read with Deno.env.get. Once saved, values can’t be read back in the dashboard. Each function can require a valid JWT.
Approve-first assistant
McManus sees your schema, policy, bucket, function and secret names, never your rows or secret values. Every change it proposes waits for you to click Apply, and then runs with your own permissions.
Backups and recovery
Nightly backups with offsite copies kept 30 days, on-demand backups, and point-in-time recovery to any second in the last 7 days. A restore keeps the data it replaces.
Careful imports
When you import from Supabase, the database password is removed from our records once the database copy finishes, and the service_role key is deleted when the import ends. Your Supabase project isn’t changed.
Your part
Shared responsibility
Some security depends on how you build. These habits matter most.
- Turn on Row Level Security for every table your app exposes, and add policies.
- Keep the service key on servers and in function secrets, never in frontend code.
- Leave “Require a valid JWT” on for functions unless they’re public webhooks, and verify webhook signatures.
- Create an on-demand backup before large migrations or imports.
- Give teammates only the permissions they need.
Da8a doesn’t currently claim any third-party security certifications. Questions about how your data is handled are covered in the privacy policy.
Start a project on a server you own.
Create an account, pick a plan or use a server you already have, and connect with supabase-js.