How Sovaria works
The path a request takes — gateway, identity, policies, the service and your database — and what each Sovaria service (Axis, Guard, Atlas, Vault, Forge, Pulse, Echo, Chrono, Ledger, Nexus…) is responsible for.
Sovaria is a set of services behind one gateway. Your app talks only to the gateway, at your project URL; the gateway works out which project and who is calling, applies limits, and hands the request to the service that owns it. Each service checks your access policies before touching your data.
What happens to one request
Edge and gateway checks
TLS ends at the edge. The gateway screens the request for injection and smuggling patterns, applies per-IP flood limits, adds security headers and works out the project from the host name (
<ref>.sovarias.inor your custom domain).Who is calling
A session token or API key is verified by Axis and turned into a verified identity (user, roles, organization, project, environment). Anything the client claims about itself is ignored.
Limits
Origin rules, rate limits and plan limits are applied. Over a limit, the request stops here with
403or429and a reason.Routing
The request goes to the service that owns the path. Where a service runs several instances, requests are spread with consistent hashing, and a circuit breaker stops sending to an instance that keeps failing.
Access policies
The service asks Guard whether this caller may do this action on this resource (How access is decided).
Your data
Allowed queries run in your project's database with the caller set for row-level security; the result goes back the same way.
Recorded
Usage is counted for billing (Ledger), the request is logged and traced (Echo), and changes to schema, policies and functions are recorded (Chrono).
Every response carries an X-Request-ID; errors also carry a trace_id. Search either in Logs & Audit to see the request's path through these steps.
The services
| Service | Responsible for |
|---|---|
| Gateway | The single entry point: TLS, project lookup, request screening, CORS and origins, rate and plan limits, routing, circuit breaking. |
| Axis | Identity: sign-up and sign-in, sessions and tokens, MFA and passkeys, organizations, members and roles, API keys, project settings, mobile apps and push. |
| Guard | Access policies: compiling and evaluating rules, policy versions, the audit chain. |
| Atlas-Rel | SQL: queries, the REST table API, transactions, schema changes, vectors in Postgres. |
| Atlas-Doc | The document store: collections, queries, transactions and live listeners. |
| Nexus | Project databases: creating them, compute sizes, pooling, idle pause, backups. |
| pg-worker | Runs project databases on worker hosts on Nexus's behalf. |
| Vault | Storage: buckets, uploads and downloads, signed links, the S3-compatible API. |
| Forge and forge-runner | Functions: deploys, versions, invocations, triggers, schedules and workflows; the runner executes your code in an isolated sandbox. |
| Egress | The outbound proxy functions use: only the hosts you allow are reachable. |
| Pulse | Realtime: WebSocket channels, presence, message replay and end-to-end encrypted channels. |
| Echo | Logs, traces and simulation: request and function logs, log drains, Simulation runs. |
| Chrono | Version history: commits, timelines, snapshots and restores of schema, policies and functions. |
| Ledger | Plans, entitlements, usage metering, invoices and payments. |
| Quorum | Coordination between services. |
| Sovariq | The AI agent that can explain and operate your project with your permissions. |
Security boundaries
- Projects are isolated: each has its own database role and data; keys and sessions work only for their own project.
- Services trust only identities the gateway verified, never what a client sends.
- Secrets (function secrets, OAuth client secrets, SMTP passwords, push keys) are encrypted at rest and never returned after you save them.
- Functions run sandboxed, reach the internet only through the egress proxy and only the hosts you list.
- Values in queries are bound as parameters by the database, never spliced into SQL.
When something fails
| Situation | You see | What to do |
|---|---|---|
| A service instance is unhealthy | Requests are routed to healthy instances; a few may get 502/503. | Retry with backoff (the SDKs do). |
| Your database is starting or paused | 503 PROJECT_MAINTENANCE | Retry shortly; the first request wakes a paused database. |
| Another change to the same thing is running | 503 RESOURCE_BUSY with Retry-After | Retry after the given seconds. |
| A limit is reached | 429 or 403 PLAN_* | Back off, or raise the limit (Plan limits). |
More in Reliability.