Security

How Vaultedo is built and run. Updated 09-NOV-2026. Report a vulnerability to reachout@opnyx.com; see also security.txt.

Built in

• Every query on customer data carries the organisation from the verified session; Postgres row-level security is the second lock, and a transaction that forgets the organisation sees nothing.
• Sign-in through Firebase (Google, Microsoft, a verified email); the server verifies the proof itself, keeps its own sessions for 12 hours, and ends them on sign-out, including "sign out everywhere".
• The API has no runtime dependency but the Postgres client; the website and console load nothing from a third party.
• Strict transport security, no framing, no referrers, a content security policy with no inline scripts.
• Rate limits per address on sign-in and on every console call; bodies are bounded; every refusal is JSON in plain words with a reference you can quote to us.
• Secrets live in one file on the server readable by one account; none is in a page, a repository, a log or a command line.
• Every change in an organisation is written to its audit log with who, when, before and after.

Operated

• Nightly database dumps kept 7 daily and 4 weekly, copied off the server the same night; a restore drill monthly.
• A security audit of the whole codebase before each release that touches sign-in, keys, money or tenancy; findings fixed before shipping.
• One region today; a second is a decision we will announce on the status page.

The API

The console talks to api.vaultedo.com. Its doors are described in an OpenAPI document at /v1/openapi.json, so your own tools can read what the console reads.

Said plainly

A web page cannot stop an operating-system screenshot, a recording, a camera, or a signed-in human reading what their session may read. Vaultedo traces and limits those; it stops robots, copies and stolen sessions.