How Growth-OS keeps our data safe
Who can see what, where the checks run, where the data lives, and what never happens quietly.
On this page
Where this comes from
This guide is distilled from docs/CONVENTIONS.md and docs/DATABASE-RUNTIME.md. When the guide and Growth-OS disagree, that document is the one to trust, and the difference is worth reporting.



Who can see what
Everything in Growth-OS belongs to a project inside our organization. What you can read and change is decided by the role recorded for you in that project, and a person with no membership sees nothing, not an empty page.
Finance is administrator-only. Every other group follows the viewer, editor, admin and owner ladder described in the roles guide.
The checks run on the server
The browser never says who you are, which organization you belong to, or which project you are allowed to read. Your identity is established from the signed-in session on the server, the project and role are looked up there, and every write is validated against a shared contract before it touches the database.
Hiding a button is a convenience, never the protection. The service behind it checks again, and a request that reaches it another way is refused the same way.
Where the data lives
Records live in our own PostgreSQL database, with the tenant written into the rows and into the indexes that read them. Live updates in the interface come through an authenticated read channel that can only ask for fixed tables, fixed columns and our own project, so nothing in a browser can widen what it receives.
Uploaded files are stored privately and reached through signed, expiring links rather than public URLs.
Source credentials are encrypted per project
A credential you add on the Sources page is encrypted, versioned and revocable, and it is held by the connection owner on the server. It is never displayed back to anybody, it is never sent to a browser, and a source with no selected site, property or dataset refuses the read rather than falling back to a default.
Nothing changes quietly
Database migrations are generated, reviewed and applied deliberately. None runs on its own, and none is edited after it has reached a shared environment.
Every record save keeps a revision, so the previous version of anything is readable in the Time Machine. Evidence quotes are checked against the transcript inside the same transaction as the write, campaign recipient lists are frozen once and never replaced, and an approved extraction cannot be quietly unapproved.
Was this page helpful?
Feedback is stored only in this browser.