Security and your data
What Relia collects, who can see it, how long it is kept, and what it never does.
Never touches your code
No repository access and no pull requests; actions only with your approval.
Scoped to your project
Every read is checked against the project that owns it.
Masked before it leaves
Database values are masked inside the SDK.
Deleted on schedule
Older than your plan's 7, 30 or 90 days? Deleted daily.
What leaves your app
Only the signals Relia needs to tell you what broke.
- Only what you turn on
- Requests, errors, database calls, server metrics and, if you turn them on, browser sessions and AI-agent runs. Nothing else.
- Database values masked
- Values in database statements are masked in the SDK, before anything leaves your server.
- Private browser sessions
- Sessions record clicks, inputs, navigation and errors. The text people type or see is not captured unless you switch it on, and screen replay is off by default.
- A key per project
- Each project sends with its own ingest key.
Who can see it
Your team, with the role you give them, and no one else.
- Isolation, tested
- Every read is scoped to the project that owns the data, and an isolation test covers every route that takes a project.
- Roles and an audit log
- Team roles are owner, admin, member and viewer. Settings show an audit log of changes and recent sign-ins.
- Deploy tokens encrypted
- Tokens for your deploy platforms (GitHub Actions, Render, Vercel and signed webhooks) are stored encrypted and are never sent back to the browser.
Where it lives and for how long
Kept for your plan's history, then deleted automatically.
- Where
- Requests, sessions and logs are stored in ClickHouse on Relia's own servers on AWS in Mumbai, India; accounts, incidents and settings in MongoDB Atlas, also on AWS in Mumbai.
- How long
- Your plan sets how far back you can look: 7, 30 or 90 days. Data older than that is deleted automatically every day, except anything an open incident still cites as evidence.
- Over your limit
- Going over your monthly units never deletes anything already stored.
Signing in
Standard, current practice for accounts and sessions.
- Tokens
- Short-lived access tokens with rotating refresh tokens; passwords follow NIST SP 800-63B; email addresses are verified.
- No account probing
- Sign-in and password reset never reveal which emails have accounts, and abuse-prone endpoints are rate limited.
- Uptime checks stay outside
- Uptime monitors can only reach public addresses, never your private network.
What Relia never does
Relia tells you what to do. Anything that touches your systems waits for a person to approve it.
- Your code
- It never has access to your repository and never changes your code. Fix plans are written from the incident's evidence, for you to apply.
- Your servers
- It never acts on them on its own. When an incident follows a deploy or a memory leak, it can propose a rollback or a restart through Render, Vercel, GitHub Actions or a signed webhook you connected. It runs only after an owner or admin approves it, you can require two different approvers, and every step is in the incident's audit trail.
- Made-up numbers
- Its write-ups only state numbers that are in your project's evidence.
Certifications and reviews
What we have today, and how to check us for your own review.
- SOC 2
- Relia does not have a SOC 2 report yet. Everything on this page is how the product works today, and we will say here when an audit is under way.
- GDPR and India's DPDP Act
- These are laws, not certificates. How we follow them is set out in our Privacy Policy and on the GDPR and data processing page, with a signed data processing agreement on request.
- Your security review
- If your team needs a security questionnaire filled in or our data processing agreement, email relia@alaknandainfoplus.com and we will send it.
Privacy and GDPR
The legal terms are in the privacy policy and the GDPR notice.