Your own encryption key (BYOK)

On Enterprise, an organization can bring its own AWS KMS key. Sovaria then encrypts the organization's storage files and database backups under that key, and can only use it with your organization's encryption context — so no other organization's requests can. You stay in control in AWS: every use of the key shows in your CloudTrail, and disabling or revoking it makes that data unreadable.

#How it works

• Files are written with S3 server-side encryption under your key (SSE-KMS); reading one needs your key.
• Backups and pause archives are encrypted with AES-256-GCM using an organization data key. Sovaria stores that data key only wrapped by your KMS key and keeps the unwrapped copy in memory for a few minutes at most.
• Every file and backup is bound to your organization: the encryption context sovaria:org_id must match, and the key policy only allows that context.

What it covers — and what it doesn't

#Set it up

1. 1

   Create a key in AWS KMS

   A symmetric key (key spec SYMMETRIC_DEFAULT, usage ENCRYPT_DECRYPT) in any region and account. Turn on automatic key rotation if you want it — that is transparent to Sovaria.

2. 2

   Add Sovaria to the key policy

   Open Organization settings › Security › Your own encryption key, click Show key policy statement, and add that statement to the key's policy. It names Sovaria's AWS role and only allows your organization's encryption context. Optionally also allow kms:DescribeKey (without the condition) so Sovaria can show the key's state.

3. 3

   Paste the key ARN

   Paste arn:aws:kms:<region>:<account>:key/<id> and confirm. Sovaria checks it end to end first — wraps and unwraps a data key, and writes and reads a file under it. Nothing changes if any check fails.

4. 4

   Re-encrypt existing files

   New files and backups use your key immediately. Click Re-encrypt files to rewrite files stored before; progress shows on the card.

{
  "Sid": "SovariaOrg<your-org-id>",
  "Effect": "Allow",
  "Principal": { "AWS": "<Sovaria's role ARN, shown in the console>" },
  "Action": ["kms:Encrypt", "kms:Decrypt", "kms:GenerateDataKey"],
  "Resource": "*",
  "Condition": { "StringEquals": { "kms:EncryptionContext:sovaria:org_id": "<your-org-id>" } }
}

Only organization owners can set, rotate or re-encrypt; owners and admins can view the status and run a check. App users and API keys of your projects can't reach these endpoints.

#Disabling or revoking the key

Disable the key, schedule its deletion, or remove the policy statement in AWS and Sovaria can no longer use it — within a few minutes, once its in-memory copy of the data key expires. From then on:

• Uploading, downloading and copying files in the organization's projects fail with 403 ENCRYPTION_KEY_UNAVAILABLE.
• New backups can't be taken and existing ones can't be restored.
• Your databases, functions and auth keep running — they don't depend on the key.
• The console card shows Not usable with the reason from KMS (for example KEY_DISABLED or KEY_ACCESS_DENIED).

Re-enable the key or restore the statement and click Check now; everything works again. If the key is deleted in AWS, data under it is gone for good — Sovaria can't recover it.

#Rotation and changing keys

• AWS automatic rotation needs nothing from you or Sovaria; KMS keeps old key material for decryption.
• Rotate data key makes a new organization data key version for new backups. Older versions stay, wrapped by your key, to decrypt older backups.
• Use a different key (a new ARN): new files and backups go under the new key. Keep the old key enabled until you have re-encrypted files and no longer need older backups — they still need it.

#Signed upload URLs

For organizations with their own key, signed upload URLs point at api.sovaria.in/api/v1/store/signed/… instead of directly at S3, so every write is encrypted under your key. The URLs work the same way for your app; download URLs are unchanged.

#Errors

#What Sovaria staff see

Staff see which organizations use their own key, the key ARN, its data key version and whether it was usable at the last check (Control Center › Compliance › Customer keys). They can ask KMS to check it again — audited with a reason — but can't change, rotate or remove your key, and never see key material.

#Plans

#Coming from Firebase or Supabase?

Moving an existing app? Migrate from Supabase or Firebase imports users (with their passwords), data, files and rules.