Move a custom backend to Sovaria
Replace parts of your own API server with Sovaria step by step: which endpoints become direct data access, functions or stay on your server; auth, files, realtime, jobs and webhooks; and a checklist for each move.
You don't have to move everything at once. Run your server and Sovaria side by side and move one piece at a time; your server can verify Sovaria sessions and call Sovaria while it shrinks.
Where each part goes
| In your backend | In Sovaria | Read |
|---|---|---|
| Database | Your project's Postgres | Migrate from PostgreSQL |
| CRUD endpoints that only check "is this the owner?" | The app reads and writes directly with the SDK; row-level security and access policies do the checks | How access is decided |
| Endpoints with business logic (payments, emails, calls to other APIs) | Functions, called over HTTPS or from the SDK | Deploying and running functions |
| Sign-up, sign-in, sessions | Sovaria Auth; your server verifies tokens with the project's JWKS | Sessions and tokens |
| File uploads | Storage buckets with per-folder rules and signed URLs | Working with files |
| WebSockets or polling | Realtime channels and database change events | Channels and connections |
| Cron jobs, queues, outgoing webhooks | Function schedules and triggers, database webhooks | Event triggers, Database webhooks |
| Staging and preview servers | Environments with their own URL and data | Environments, staging and deploying to production |
Run both side by side
- Move sign-in first: once users have Sovaria sessions, your server checks their tokens (ES256, keys from
/auth/v1/.well-known/jwks.json) instead of its own. - Your server can act as the user (forward their token, so Sovaria's rules apply) or as itself with a service role key — then it must check permissions itself (JavaScript: React, Next.js, Vite and Node, Python: install and configure).
- Move endpoints one at a time: make the app call Sovaria for that feature, watch the logs, then delete the endpoint.
Files
Copy existing files with the S3-compatible API — aws s3 cp --recursive or rclone work against it (S3-compatible storage access) — or sov storage upload for a few. Keep the same paths, with the user's id as the first folder where files belong to a user, so own-folder rules apply (Access, links and delivery).
Checklist for each piece you move
- Rules written and checked:
sov rules testcases for who may and may not (Access rules tests), and a simulation run. - Secrets moved into function secrets, never into app code.
- Errors handled in the app:
SovariaErrorcodes (JavaScript: install and configure). - Tested against staging with test users (Testing your app).
- Old endpoint kept until traffic to it stops, then removed.
Things that work differently
- Functions run in a sandbox with time and memory limits and an allow-list of outbound hosts — long-running workers and open sockets belong elsewhere (Function memory, timeout and limits).
- Database change events say that rows changed, not what they contain; clients re-read through their rules (Database change events).
- Image resizing isn't available yet; resize before upload (Access, links and delivery).
Something unclear or missing on this page?Tell us