briven· techsecurity
every claim on this page names the thing that makes it true — a statement, a setting, a measured number. where briven does not do something, it says so rather than leaving you to find out.
found a problem? write to security@flndrn.com. there is no bounty programme and no legal threat either — you will get a human reply, and credit if you want it.
isolation
each database is a real postgresql database with its own owning role, and the first thing done to it after it exists is to take away the right for anybody else in the cluster to connect. one statement does that, and without it every customer could reach every other customer's database — so it is not a setting, it is the boundary.
a statement is stopped after 30 seconds, a transaction left open is closed after 60, and one database holds at most 20 connections. these are set on your login rather than on the database, because the owner of a database can raise a limit set on the database and cannot raise one set on the role.
a dedicated database is a postgresql container to itself: 192 mb of memory, half a cpu, 256 processes, no swap to escape into, and no ability to gain privileges. those figures were read out of the kernel's own cgroup files on the live machine, not out of a config file that says what was intended.
the application does not hold the key to the container engine. a separate small helper does, and it accepts a fixed list of instructions — briven can name a tenant, and cannot choose an image, a mount, a network or a limit. a bug in the application therefore cannot become a bug in the host.
on the free tier your database shares a postgresql server with other customers. the separation is at the database and role level described above, not a machine of your own — that is what the dedicated tier is for. briven does not use row-level security anywhere.
in transit
every public endpoint is served over tls with a let's encrypt certificate. strict-transport-security is set for a year including subdomains, the frame and content-type protections are on, and the web server's own administrative interface is switched off entirely.
the control plane verifies the pooler's certificate and its hostname against one pinned certificate — stricter than trusting a public authority, because exactly one certificate is acceptable. if that certificate is missing the code raises an error rather than quietly continuing without verification.
the connection string briven issues asks for sslmode=require, which encrypts the connection but does not check the certificate against anything. and the pooler still accepts a client that insists on plain tcp. that is weaker than it sounds and it is written here rather than left for you to discover.
credentials
a database password is stored encrypted with aes-256-gcm, a fresh random nonce for every value, and the key held outside the database — so a stolen copy of briven's own database yields ciphertext and nothing else. it is encrypted rather than hashed because 'show me my connection string' is a thing you need daily and a hash cannot answer it. every reveal is written to the audit log.
a key is 256 bits of randomness shown to you once. briven keeps a sha-256 hash of it and the last four characters, so a key can be recognised and named but never reproduced — not by support, not by an attacker with the database. comparison is done in constant time so the hash cannot be guessed a character at a time.
rotating a database credential changes the password, updates the pooler's own copy, and then cuts every live session — and tells you how many it cut. the test that proves it is not that the new password works; it is that postgresql refuses the old one. a leaked connection string is dead within the second.
there is no grace period. a role has exactly one password, so the change is immediate and anything still holding the old string will fail until you redeploy it. and rotation lives on the api and the cli today — there is no button for it in the dashboard yet.
durability
a full backup runs every night, and the write-ahead log is archived continuously between them. that second half is what makes a restore to a chosen second possible rather than a restore to last night.
on 19 august 2026, on the live server: a row was written an hour after the backup was taken, then deleted, and then recovered to a chosen second. it existed in no backup file, so what brought it back was the archived log — which is the only way to know the archiving works.
every restore goes to a new database beside the original. a recovery tool that can overwrite the thing you are trying to recover is a second outage waiting for a bad afternoon.
you can name a restore point and go back to it — that is self-service, and it builds a new database. recovering to an arbitrary timestamp from the nightly backup is an operator job done by a human on request, not a button. those are two different features and briven will not blur them into one.
the backup repository currently lives on the same machine as the databases. it protects you against a dropped table, a bad migration or a corrupted cluster — it does not protect you against losing that machine. off-site copies are being wired now, and this paragraph changes on the day they run. the restore proven above was of briven’s own control database; a customer database restore has not yet been performed end to end.
accounts
a password with a strength rule the server enforces rather than the browser suggesting, or a short-lived code sent to your address. the code expires in ten minutes and the number of attempts is capped, because six digits is not many.
every sign-in records the address it came from and emails you about it. a stolen password that is used is a stolen password you hear about.
every action taken in an organisation is appended and never rewritten: who, what, when. it comes with the pro plan and above — the pricing page says exactly which.
the gaps
none of the following exists. if your requirement is on this list, briven is not the right platform for you today, and you should know that now rather than after a migration.
no soc 2, no iso 27001, no hipaa, no pci. briven is run by one small independent company and has never been through an external audit. anybody claiming otherwise on our behalf is wrong.
sign-in is a password or an emailed code. there is no second factor, no hardware key, no saml or oidc single sign-on, and no scim provisioning.
briven secures your account with briven. it does not offer a hosted login system for your application's own end users, and there is no row-level security layer to go with one.
there is no contractual availability percentage, because briven does not yet measure availability well enough to stand behind a number. the sla page explains what that means in practice.
one region, one primary, fixed resources per plan. these were ruled out deliberately rather than postponed — the homepage explains why each one is a decision and not a delay.
nothing on briven meters you into a bill today. no payment provider is connected and every usage rate in the product is set to zero. the pricing page says the same thing.
this page describes the platform as it stands. the terms and the data processing agreement are the documents that bind us; where a sentence here and a sentence there disagree, the legal document wins and this page is the bug.