trust

last updated 2026-08-20 · briven.tech · operated by flndrn Limited (Cyprus)

what the platform is

Briven is a hosted PostgreSQL platform. Concretely, that means:

• PostgreSQL 18 with pgvector 0.8.6 — real Postgres, standard wire protocol, created in seconds. Your existing driver, ORM and migration tool work unchanged, and vector search is a column type rather than a second database.
• One front door — every customer connection goes through a PgBouncer connection pooler. Nothing else is exposed, and an idle database holds zero connections.
• SQL over plain HTTP — a single POST endpoint for environments that cannot hold a TCP connection. It speaks Neon’s HTTP protocol, so a stock, unmodified @neondatabase/serverless client talks to it as-is.
• API keys you can narrow — a key can be scoped to one database and optionally made read-only. Keys are stored as SHA-256 hashes and compared in constant time; the plaintext is shown once and never again.
• Object storage per database — S3-compatible buckets, so the standard S3 clients work.
• Organisations, roles, permissions and an audit log — custom roles with per-resource permissions, and a record of every action taken in the organisation.
• Backups, and a restore that has actually been performed — a full backup nightly at 02:00 UTC plus continuous write-ahead-log archiving, using pgBackRest, with seven full backups retained. On 19 August 2026 a restore was carried out on the live server and recovered a row that existed in no backup file — it came out of the write-ahead log. A restore always lands in a new database beside the original, never over it. The honest limit: the backup repository currently sits on the same machine as the databases, so it protects you against a dropped table, a bad migration or a corrupted cluster, but not against losing that machine. Off-site copies are being wired now — keep your own pg_dump until they exist.
• Branching — a copy of a database, made for you to break. A 256 MB database was copied in 524 ms, and the copy is independent from the moment it exists: writing to it cannot touch the original.
• Change history and undo — a per-row change log recording who changed what and when, with an undo that refuses rather than guesses when the row has been changed again since. Restore points land in a new database too. This is a change log with an undo, not time travel: there is no querying the database as it stood at an arbitrary second.
• Realtime — changes pushed to subscribers as they happen, with commit-to-delivery measured at 11 ms against a 200 ms budget.

Security mechanisms and their limits: /security. Subprocessors list: /subprocessors. Status: /status. Plans: /pricing.

what we do not offer yet

Being first to say this is the point of a trust page. As of the date above, the platform does not provide:

• No certification of any kind. No SOC 2, no ISO 27001, no HIPAA, no PCI DSS. No external audit has ever been carried out on briven. If your procurement process needs a report to attach, there is nothing to send you, and this page will not imply otherwise — see the DPA for what is offered instead.
• SSO, SCIM or MFA. No SAML, no OIDC federation, no directory sync, no TOTP and no passkeys. Even dashboard sign-in has no social providers: it is email and password, or a one-time code sent to your email. Sessions last 30 days on a sliding basis, and sign-in alerts are emailed.
• An end-user auth product for your application. The sign-in on briven.tech is for the dashboard only. We do not host logins for your users.
• Off-site backups. Backups exist and a restore has been proven, but the repository is on the same machine as the databases. That is protection against a mistake, not against losing the machine. This is the most important line on this page.
• Multi-region, read replicas or autoscaling. One region, one machine, by deliberate choice rather than by delay. It also means there is no contractual uptime percentage — the reasoning is set out in full at /sla.
• Required TLS on database connections. Connection strings use sslmode=require, which encrypts the connection but does not verify the certificate, and the pooler will still accept a client that insists on plain TCP. Use verify-full from your side if that matters to you.
• Row-level security, a functions runtime, or logical replication. Not built.

If one of these is a hard requirement for you today, briven is not the right choice yet, and we would rather you knew that before you migrated than after.

where data lives

The whole platform runs as a single deployment on one server: the dashboard, the control-plane database, a shared PostgreSQL cluster where free-tier databases live, per-project PostgreSQL containers on paid plans, the connection pooler, the object store, and the TLS terminator that fetches certificates from Let’s Encrypt. Customer data is isolated per database — its own database and its own login role, with connect rights revoked from everyone else in the cluster.

We are not naming the hosting provider or the data-centre region on this page. That is not evasion and it is not a secret: it is that the claim cannot currently be verified from the inside, and a trust page is the last place to publish something that has not been checked. If your evaluation depends on knowing where the machine physically is — and for many it rightly does — write to legal@flndrn.com and you will get the answer directly. Dedicated capacity and data-residency requirements are handled case-by-case at the same address.

encryption

• TLS on every public endpoint.
• Stored database credentials: AES-256-GCM at rest with a platform-held key.
• Session cookies: HTTP-only, Secure in production.
• API keys: SHA-256 hashed; only short suffixes displayed.

access & audit

Platform actions — creating or deleting a database, changing a member, revoking a key, changing a role — are written to an append-only audit log, which is available on the pro plan and above. IPs are hashed before storage where the Privacy Policy requires it.

incident disclosure

We aim to disclose incidents that affect customer data within 72 hours of detection to affected accounts and publish a post-mortem here within 30 days when material. Report security issues to security@flndrn.com.

legal contacts

Privacy & DPA: legal@flndrn.com · Operator: flndrn Limited, Limassol, Cyprus. The Terms and Privacy Policy live under this site’s legal section.