> ## Documentation Index > Fetch the complete documentation index at: https://renor.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Security > Where your Renor memory lives, how workspaces are kept apart, who else sees memory text, retention and deletion, and what Renor does not claim. This page says only what Renor's code and its public legal pages already establish. Sentences about live infrastructure are recorded, with the date each was checked, in the "Live checks" section at the end of this page. ## Where your memory lives Memory content is stored on Renor-controlled infrastructure hosted on Google Cloud, currently in the `us-central1` region (United States): one Compute Engine persistent disk, encrypted at rest with Google-managed keys, the Google Cloud default (no customer-managed key). The dashboard shows it in your browser when you ask, but it is not stored there, and it is never in a public repository. Account records (sign-in, workspace, plan) are in Supabase. Each workspace has its own memory directory, its own search index and its own server process. That process listens on the host's loopback interface only, behind the one proxy that terminates TLS and the gateway behind it, so it is not reachable from the internet directly. ## Keeping workspaces apart The gateway looks up which workspace a connection belongs to on every request and refuses to route when it cannot: a missing or unknown workspace fails, it never falls back to another one. Revoking a connection token takes effect on the next request. Every live workspace runs as its own operating-system account, with no login shell and no home directory, and its data directories are readable by that account alone. One limit remains: the gateway and the workspace engines still share one operator credential (the gateway secret), so isolation between workspaces rests partly on the gateway and engines refusing requests; per-workspace credentials are not in place yet. The engine and the gateway fail closed: a request without a valid owner token reads and writes nothing. ## Signing in and connecting An AI client connects with the standard MCP sign-in (OAuth 2.1 with PKCE) as the workspace owner. Connection tokens are credentials: they are stored hashed and can be revoked from the dashboard, which stops that client at once. ## Who else sees your memory text Only the processors needed to run search and to show your memory in the dashboard. * Supabase's function runtime relays memory text and queries between the dashboard and the memory service (saving, recalling, browsing, reading and exporting; an import goes straight to the memory service) and does not store them. * Every hosted workspace has search by meaning on, so the text of notes and the queries needed for it go to **Google Vertex AI** (`gemini-embedding-001`, 768 dimensions). * Write-time summaries, which would send each saved note to Fireworks AI (US-only endpoint), are off by default and used only where a deployment turns them on. * Analytics events describe actions, not content: no memory text, prompt or query is sent to analytics or to error reporting. * Payments are handled by Paddle as merchant of record; card details never reach Renor. Renor does not use your memory content to train models, does not sell it, and does not share it with other users. ## Retention, backups and deletion Data is kept while your account is active. Retiring a memory removes it from every read and search and can be undone; it is not erasure. A retired note or log entry can then be deleted permanently on the dashboard's Memories page, by you only, and that cannot be undone; a retired fact stays in the history record. Erasing a fact, and account deletion, is by email to [privacy@renor.cloud](mailto:privacy@renor.cloud) (see [Export and your data](/export-and-your-data)). Renor's analytics, error-reporting and email providers keep their own logs for their own retention periods; deleting your account does not erase events already sent to them. Paddle, our merchant of record, keeps its own payment records as the law requires; deleting an account cancels the subscription but does not erase those records. A snapshot policy snapshots the disk daily at 08:00 UTC and keeps each snapshot for 7 days. Deletion has not yet been validated against restored snapshots, so Renor does not claim that deleted data is gone from backup copies. ## What Renor does not claim * There is no uptime SLA, and no public status page. * There is no published third-party security audit or certification. * A call that fails because the workspace is unavailable writes nothing and is not queued. If a breach affects your data, Renor will notify you and the authorities as the law requires. Questions: [privacy@renor.cloud](mailto:privacy@renor.cloud). ## Live checks, and when they ran A sentence about live infrastructure can change without a code change, so each one that is verified on the host is recorded here with its date. The date is when the check ran, not an expiry: an older date means an older check, not a withdrawn claim. 2026-10-07: the disk was encrypted at rest with Google-managed keys, with no customer-managed key; the live workspaces (six at the time) each ran under their own operating-system account, with no login shell and no home directory; every hosted workspace had search by meaning on; and the daily snapshot policy had produced snapshots for October 4 to 7. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.