--- title: "Security, backups and status" description: "Why Plurabase is not ready for production data: what protects a pilot project today, what is missing, and which safeguards are in development." slug: "security-status" locale: "en" group: "platform" order: 3 last_reviewed: 2026-10-26 --- # Security, backups and status An internal static review on 2026-10-18 (no code was executed) rated Plurabase **not ready for customers**, including for the owner's own real data. The main reasons: the pilot has no backups, no alert reaches a person when something fails, the pilot is not open to the public so the operator still admits every account, and it runs on a KVM virtual machine on a dedicated server. Do not store data in the pilot that you cannot lose. The [facts page](/docs/facts/) has the status of every capability. ## What is in place - **Private network only.** The pilot is reachable only over Tailscale from devices the operator admits. Nothing is exposed to the public internet. - **Platform accounts on the pilot.** Sign-up with email verification, TOTP MFA, password reset and recovery codes runs on GoTrue's native endpoints with server-held sessions (ADR-0018). Its email goes out through the operator's provider. The pilot is not open to the public, so the operator admits every account. - **Role checks on every request.** The console, the management API, the Studio gate, the MCP server and Sites check the caller's current organization and project role. That review read the code and found no path for a `developer` or `read_only` member to obtain service-role keys, privileged SQL or secrets. It did not try to exploit each project's API proxy, the Git handlers or the authorization of shared SQL. - **Agent tokens bound to one project.** MCP tokens name one project, expire in 24 hours or 7 days, can be restricted or revoked from the console, and are checked against the member's current role on every call. Write tools need an `operation_id`, and an uncertain result stops further writes until the operator reconciles it. - **Per-project isolation.** Each project has its own PostgreSQL credentials, internal container network and memory, CPU and process limits. Database ports are not published. - **Frontends cannot reach secrets.** A Site receives only the publishable key. ZIPs are decoded by an unprivileged process that rejects path traversal, links, special files and forged sizes. Site code runs on an opaque origin and cannot read console cookies. ## What is missing ### Backups > Status: In development (ops.backups) No backups run today. Daily encrypted logical backups to storage outside the host, with a restore drill on another machine and dead-man alerts (ADR-0020), are written and await their first native run, as is an operations health observer that reports failed services, low disk or memory, an expiring certificate and stale backups to its own external check (ADR-0031). ### Point-in-time recovery > Status: In development (database.pitr) Continuous WAL archiving to the same off-host repository, a weekly base backup and a drill that restores a project to a chosen moment on another machine (ADR-0031) are written and await their first native run. They require the daily backups to be enabled first. Until they run, a lost or damaged database cannot be restored to an earlier moment. ### Key rotation > Status: In development (projects.key-rotation) On the pilot host, owners and admins can see a project's secret key and its Studio credential, and nothing rotates them. Someone removed from a team may keep secrets they already saw. Changes of role apply to new requests within seconds, not to secrets already copied. Key rotation is written and not deployed (ADR-0030). An owner or admin rotates a project's secret key, service JWTs and Studio credential from the console, and removing or demoting an owner or admin rotates the projects they lost, at most once every 5 minutes per project. A rotation finishes only when the gateway, PostgREST, GoTrue and Storage each refuse the old keys. It also retires the legacy anon JWT, so published Sites releases and builds that embed it stop answering until they are published again; clients that use the publishable key keep working. The same code stops showing the Studio credential in the console. Database passwords are not rotated, and anything a removed admin created stays. ### Hostile tenants Isolation between projects has been reviewed and partly tested, but not attacked with hostile workloads. Untrusted build code is meant to run in an isolated virtual machine; that path is not active. A stricter container profile for each project's services (no unneeded Linux capabilities, no core files, a bounded temporary directory for functions) and a host firewall table that keeps project networks away from the host, the cloud metadata service and each other are written but off: the pilot enables neither until a run with hostile workloads on a disposable machine passes. ### Compliance Plurabase holds no SOC 2, HIPAA or other certification and offers no SLA. ## Recovering a frontend Rolling back a Site switches the published release immediately. It never changes database tables, Auth users or migrations, and it is not a database backup.