Security and reliability
Checked on every request. Measured, with dates.
Sovaria decides who is calling and what they may do before any data is touched, keeps each customer apart, and writes down what happened. Every figure on this page has the date it was measured, and what isn’t in place yet says so.
Every request, checked in order
Thirteen layers sit between the internet and your data. In the console, Simulation › Request security traces the ten kinds of request your project serves (reading and writing rows, SQL, documents, files, realtime, function calls, webhooks, sign-in and your own server) through each layer and flags any that is off.
How simulation works- TLS. The connection is encrypted; plain HTTP is refused.
- Firewall. Bots, scanners, injection and path tricks are stopped before anything else.
- Allowed origins. Browsers may call only from the websites you list.
- Rate limits. Per IP, per user and per key.
- App attestation. Mobile calls must come from your real app.
- CAPTCHA. Sign-ups and sign-ins prove a person is there.
- Key or token. Who is calling, and is it still valid.
- MFA. A second factor when your settings ask for one.
- Access rules. Your policies decide; a DENY always wins, and no rule means no.
- Row-level security. Postgres returns and changes only the rows the caller may see.
- Idempotency. A retried write runs once.
- Plan limits. Quotas and your spend cap apply.
- Audit log. The request is written to a tamper-evident log.
What protects your app’s data
These come from how the gateway, the policy engine and the SDKs are built. They are on for every project.
How customers are kept apart
One customer must never reach another’s data. This is how, and the isolation tests below check that it keeps holding.
How we secure the platform- Each project’s data lives in its own Postgres database.
- Which organization and project a request acts on comes from its session or key, checked on the server. Naming another project in a header, path or body is refused.
- Functions run in a gVisor sandbox with no route to Sovaria’s internal network; outbound calls go only where you allow them.
- Each Sovaria service has its own database login with only the permissions it needs.
- Staff reach customer data only through audited tools and time-limited support grants, from a Control Center that needs a device certificate, a password and a one-time code.
Encryption and backups
Data is stored in India, in one AWS region (Asia Pacific, Mumbai, ap-south-1); other regions in our code are not offered. Production runs in one AWS region today, with one availability zone for the platform database; multi-zone is on the roadmap.
- In transit
- TLS 1.2 and 1.3 only on every public endpoint, with HSTS and strict security headers.
- At rest
- Encrypted database storage, encrypted backups (AES-256 / AES-GCM), and secrets encrypted in the database.
- Your own key
- Files and database backups encrypted under a key in your AWS KMS. Revoke it and nobody can read them, Sovaria included.
- Backups
- Daily encrypted backups, and point-in-time recovery for dedicated project databases.
- Uploads
- Files can be checked for malware before they are stored, on every way in: SDK, console, signed URLs, resumable uploads and the S3 API.
Your own encryption key · Backups and recovery · Malware scanning
Our testing program
The scans run against production with test accounts and never change real data; a failure is handled as an incident. Each figure below has its date.
- ~11,000
- automated tests across our services, gateway, apps, SDKs and CLI7 Nov 2026
- 237 / 237
- red-team attacks on the Sovariq AI assistant contained, against a real model7 Nov 2026
- 8 of 8
- high-severity findings of the latest full code audit fixed, each with a regression test (7 live, 1 rolling out)7 Nov 2026
- 0
- known vulnerabilities in 111 pinned service dependencies, the gateway and the web apps7 Nov 2026
| Test | When | What it proves |
|---|---|---|
| Full security code audit | Repeated since October 2026; latest 7 Nov 2026 | Ten reviewers, one per area, read every repository; each finding is checked against the source and fixed with a regression test. |
| AI assistant red-team suite | Every Sovariq change; real-model run 7 Nov 2026 | Prompt injection in rows and web pages, hidden text, credential exfiltration and unsafe tool calls are contained even when the model is fooled. |
| Cross-tenant isolation matrix | After every deploy (read-only part); weekly in full (set up; verification pending) | One account’s session is refused on another account’s SQL, documents, storage, functions, realtime and knowledge bases. |
| Penetration-test suite | Weekly (set up; verification pending) | TLS, forged and expired tokens, injection, path traversal, SSRF, rate limits, prompt injection and database escape attempts. |
| OWASP ZAP baseline | Weekly (set up; verification pending) | A passive scan of the console, the docs and the API. |
| Dependency and image scanning | Every CI build; weekly CI set up, verification pending | No known fixable high or critical vulnerability in what we ship. |
| Function sandbox checks | Every deploy of the function runtime | Functions can’t open raw sockets, reach cloud metadata or start processes they shouldn’t. |
Signed builds
Service images are built by CI from our main branch, scanned, shipped with an SBOM and build provenance, and signed with Sigstore. The server checks the signature before an image starts. Not yet everywhere: a deploy can still build on the server when no CI image exists, and moving every service to signed images is under way.
Benchmarks we can back
Measured, not estimated, on today’s production setup: one 2-vCPU server in Mumbai. Single requests are fast; sustained throughput on this server tops out near 80 data requests a second (23 Oct 2026), and more cores raise it. The method and every number are on the benchmarks page.
| What | Result | Measured |
|---|---|---|
| SQL read by primary key, anon key, row-level security on (in-region client) | p50 21.7 ms · p95 41.3 ms | 24 Oct 2026 |
| Documents: query 10 documents (in-region client) | p50 24.9 ms · p95 34.9 ms | 24 Oct 2026 |
| Tables and documents from a laptop in India to Mumbai | p50 44–57 ms | 5 Nov 2026 |
| Console pages: 50,000 requests in flight at once | all served in 4.3 s (~11,700 pages/s) | 23 Oct 2026 |
| Realtime fan-out, 4,000 subscribers, 1 KB message (one engine core, lab machine) | delivery p50 68 ms; 41 µs of server CPU per delivery | 23 Oct 2026 |
| Function warm start, per runtime (lab machine, production runner image) | p50 34–79 ms | 24 Oct 2026 |
Benchmarks: setup, method and how to run them yourself · Performance
Reliability
What keeps your data safe when something breaks, and what isn’t there yet.
- Backups
- Daily, encrypted with AES-256 before they leave the server (project database backups with AES-256-GCM). A monthly automatic restore test into a throwaway database is set up; verification of its recent runs is pending.
- Point-in-time recovery
- For dedicated project databases (Pro and higher): restore to any moment in the window; at most a minute or two of changes is lost.
- Monitoring
- Health, capacity, backups, certificates and error rates every 5 minutes; failures open an incident and alert on-call.
- Service objectives
- 99 % of API requests answered within 1 second; fewer than 0.1 % fail with a server error.
- Where it runs
- One AWS region (Mumbai), with one availability zone for the platform database. A second zone is planned; we say so rather than imply it.
Reliability · Backups and recovery · Status and incident history
Where compliance stands
We never list a certification before the auditor’s report or certificate exists. The trust center shows every control and its state; the control map shows how each SOC 2 and HIPAA technical control is met. For a vendor review, start from our security questionnaire answers and the shared responsibility split.
SOC 2 Type I
In progressReadiness in progress; no audit yet. Our policies are written and awaiting sign-off, every control is mapped, and automated evidence collection is built; its first published run is pending. No auditor has issued a report.
DetailsISO/IEC 27001:2022
Not certifiedControls are mapped to Annex A. Certification comes after SOC 2 Type I.
DetailsHIPAA
Ready, BAA pendingHIPAA-ready on Enterprise: MFA for every member, session limits, 6-year audit retention, a PHI access log, encrypted-only backups and a safeguards report from your live setup. We can’t sign a BAA for protected health information until we accept the AWS BAA (not yet done). No third-party assessment yet.
DetailsDPDP Act (India)
In placeAn itemised privacy notice, consent recorded on the server with its version, one-click withdrawal and data download.
DetailsGDPR
In placeExport and erasure in Account › Privacy, a public DPA with Standard Contractual Clauses, and a list of subprocessors.
DetailsPCI DSS
Not storedSovaria never stores card numbers; payments go through Razorpay, which is PCI DSS certified.
External penetration test
Not done yetOur own automated tests and code audits run today; an independent test is planned.
Your part, and ours
Security is shared. Sovaria runs the platform; you decide who may read and change what in your project.
- Keep the service role key on servers; never ship it in an app or commit it.
- Write access policies and row-level security for every table and bucket that holds user data. Security Advisor flags gaps.
- Turn on MFA for your console account and require it for your organization.
- Decide which projects hold regulated data, and use HIPAA mode or your own key where needed.
Found a vulnerability?
Email tech@sovaria.in with “Security” in the subject. The address is also in security.txt.
How we handle reportsSeen a site or app on Sovaria used for phishing, malware or spam? Every release is checked before it goes live, and anyone can report one.
Report abuse