Skip to main content

2 posts tagged with "data-residency"

View All Tags

Bring Your Own Backup Bucket

· 3 min read
FoundryDB Team
Engineering @ FoundryDB

Backups are the one copy of your data you hope you never need and cannot afford to get wrong. Until now, FoundryDB wrote them to storage we manage for you, which is the right default for most people. But if you have a data-residency requirement, an existing object-storage account you already audit, or a compliance rule that says backups live in a bucket you control, "the right default" is not enough. Now you can point a service's backups at your own S3-compatible bucket. We call it bring your own backup bucket, and it is live today.

We Run the Login. You Keep the Users.

· 5 min read
FoundryDB Team
Engineering @ FoundryDB

Every app needs login. Almost nobody wants to build it. So you grab a hosted identity service, ship in an afternoon, and quietly sign a deal nobody prints on the pricing page: your users now live in someone else's database, in someone else's region. Their emails. Their sessions. Their second-factor secrets. All of it sitting inside a control plane you do not run and cannot see into. With Auth0, Clerk, or Cognito, that is the trade. Convenient SDK on top, your users hostage underneath.

FoundryDB App Auth flips it. We run the login service for you: a standard OIDC issuer with hosted, themeable login pages, zero UI to build. But the people signing in stay yours. Their identities, sessions, refresh tokens, and MFA secrets land in a schema inside your own PostgreSQL database, in your region. Our control plane never sees a single one. We run the login. You keep the users.

App Auth · managed OIDC, your database
TOKEN Issuer signed the JWT · App validated it against the JWKS
End Userbrowserlogin →OIDC Issuerauth-<id>⇢ verify _mdb_authYour PostgreSQL_mdb_auth← JWTYour Appvalidates
App / token (JWT)OIDC issuerYour PostgreSQL (_mdb_auth)Social login (optional)Control planeconfig only (dotted)