4 posts tagged with "auth"

Building the backend for a new app is the same checklist every time. Provision a database. Put a GraphQL or REST layer in front of it. Stand up sign-in so users have accounts. Open a bucket for uploads. Then spend the rest of the day wiring those four pieces together with connection strings, access keys, and issuer URLs you paste between environment files. The product you actually wanted was always a day of plumbing away.

The Launch a realtime backend stack collapses that into one button. You get a complete backend on your own PostgreSQL: an instant real-time GraphQL API, end-user auth, and an object-storage bucket, wired together and EU-resident, in minutes, with no backend code to write.

Every product needs the same first afternoon of plumbing. Provision a database. Stand up an admin tool. Build sign-in and token issuance, or wire in a third party that holds your users hostage. Find somewhere to put uploads. Point a domain at it and get a certificate. None of it is the product you set out to build, and all of it has to exist before the product can.

The Launch a SaaS starter stack collapses that into one button. You get a SaaS backend in a box: your own PostgreSQL with a Directus studio over it, end-user auth, object storage, and a custom domain, wired together and EU-resident, in minutes.

Every platform you have ever shipped on hands you a bag of parts. A database here. A bucket there. An auth provider, a connection string, a set of S3 keys, a firewall rule, an environment variable to remember on Monday. Each part is real and each part works, but none of them know about each other. The wiring is the project. You spend the first afternoon copying credentials between dashboards before your app renders a single useful screen.

Today we ship the opposite of a bag of parts. create-foundry-app is live. One command scaffolds a Next.js app that already declares what it needs. One deploy provisions every one of those resources on FoundryDB, wires them together, and injects the credentials into the running app. No connection strings to copy. No firewall rules to open. No API keys to paste. You write the app and you ship the wired whole, resident in Europe, in one command and one deploy.

And because we know the first question every serious developer asks: it is open-source, it is MIT, and every primitive maps to an open standard, so the same app runs anywhere. You own the convenience, not a lock.

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.