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. The helper is @briven/serverless.
• 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. A second copy is taken to another machine every night; on 8 September 2026 a throwaway customer database was restored from that copy. The honest limit: if this whole machine is gone, someone still has to restore onto a new box. Keep your own pg_dump.
• 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 5 ms on the live server against a 200 ms budget.

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

what we do not offer yet

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 — 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.
• Automatic failover if this machine dies. A second copy of backups lives on another machine and was restored from on 8 September 2026. There is still no second machine for the app itself. Recovery is “restore onto a new box”, not an automatic switch.
• Multi-region / a second machine. One region, one machine, by deliberate choice rather than by delay. Read replicas and live resize exist on this same box — they do not buy high availability. 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 or logical replication. Not built.
• Functions that can call the rest of the internet. A functions runtime exists — your TypeScript, next to your database — but the sandbox has no network, no filesystem and no environment, and it is off by default. The reference is /docs/functions.

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 yet. That is not evasion and it is not a secret: the location cannot currently be verified from the inside, and an unverified location is not one to publish. 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.