9 posts tagged with "app-hosting"

You have a database full of tables. Now you want to see them. So you go find a BI tool, spin up a server for it, open a firewall rule, copy a connection string, paste in a host and a port and a username and a password, pick the right SSL mode, and after twenty minutes of yak-shaving you finally reach a login screen. Then you do it again next week when someone asks for a CMS, or a GraphQL API, or a no-code grid your ops team can edit.

That whole detour is now one click. From any FoundryDB database, click Add app, pick what you want, and the platform provisions a connected companion application for you. It auto-connects to your database over a private network with its own scoped credentials, serves it at its own subdomain with automatic HTTPS, and meters it like any other service. No config, no connection strings, no separate hosting to babysit. One click from data to a working app.

When the edge gateway launched, you could put a custom domain in front of your app, get an automatic certificate, cache responses, rate limit per IP, and run a detect-only WAF. That covered the headline cases. But production has a longer list: a permanent redirect for a moved path, an HSTS header you can finally turn on, a CORS policy for the front end on another domain, an IP allow list for a staging environment, a maintenance page during a deploy. Each of those used to mean code in your origin or config you maintained yourself.

Now the full edge configuration surface is exposed per app, in the Domains & Edge tab and across the API. Redirects, headers, CORS, access control, compression, limits, and a WAF that can now block, all configured per app and applied across every EU point of presence without touching your container or redeploying anything.

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 Hosting started by putting your app next to your data: a container on a dedicated VM, served over HTTPS, attached to your managed databases over a private SDN with credentials injected as env vars. The launch post hinted at where this goes next, "more than one app talking to a shared set of databases," and that is exactly what shipped.

Two features this round. First, an app can now attach to another app, not just a database, so a frontend can call an internal API entirely over the private network with no public exposure and no credentials to manage. Second, every deployment revision now records a deploy log: the ordered steps the platform ran to roll that revision out, with each step's status and duration. Here is each one.

App Hosting runs your container next to your data and gives it a URL at https://{name}.foundrydb.com. That is enough to ship, but production wants more in front of the origin: your own domain, a real certificate that renews itself, a cache so repeat requests never touch your container, a rate limit so one client cannot drown the rest, and a first line of defense against the obvious injection attempts. Until now each of those was something you bolted on yourself.

FoundryDB now runs that layer for you. The edge gateway is a managed HTTP front end that sits between the public internet and your app's origin. You turn on the pieces you want through one settings call, point a domain at us, and the platform handles certificates, caching, limits, inspection, and the analytics that tell you what is happening.

Your database holds the rows. Your app serves the requests. But almost everything real also produces bytes that are not rows: user uploads, generated PDFs, exports, image thumbnails, model artifacts, documents you want to search later. Until today, holding those bytes meant leaving FoundryDB for a separate object storage account, a separate console, a separate bill, a separate credential model. Your data lived in one place and your blobs lived somewhere else.

Not anymore. FoundryDB Files is live. It is per-org, S3-compatible object storage, built into the platform and hosted in Europe, and it lives right next to the databases and apps you already run here. Provision a bucket in seconds with no VM to size. Reach it from any S3 SDK or tool you already know. Hand out presigned URLs for browser-direct uploads. And, the part we are most excited about, attach a bucket to a hosted app and watch it just work, with credentials the platform mints, scopes, injects, and revokes for you.

App Hosting launched with apps served over HTTPS, attached to your managed databases on a private network, and redeployed with a blue/green flip that keeps the old container serving if the new one fails to start. That covered shipping. It did not cover the day a deploy goes wrong, the day a deploy goes wrong and your container starts but never becomes ready, or the day the app outgrows its plan under load.

Four features shipped since launch close those gaps. Every deploy is now an immutable revision you can roll back to in one request. Health checks gate the blue/green cutover so a container that comes up broken never takes traffic. Vertical scaling is a live hot resize with no reboot. And CPU and memory alerts now surface on the app detail page. Here is each one.

App Hosting launched with apps served at https://{name}.foundrydb.com from public images. That covers the demo and the internal tool. It does not cover the two things every real deployment needs: your app on your domain, and your app built from a private image. Both shipped alongside the launch, and both are designed so you never hand a plaintext secret around or click through a certificate wizard.

This post covers the two-certificate model behind custom domains and the write-only credential model behind private registries.

Your database lives on FoundryDB. Your app lives somewhere else: a separate PaaS, a VM you babysit, a Kubernetes cluster you would rather not think about. Every query crosses the public internet, hits a firewall rule you opened by IP, and crawls back. Two sets of credentials, two networks, two bills, and a latency floor set by whatever the internet feels like today. That gap is where most of the operational pain in a small-to-medium stack actually lives.

Today we close it. App Hosting on FoundryDB is live. Run your container on a dedicated VM, reachable over HTTPS, wired straight into your managed databases over a private network with credentials handed to it automatically. You deploy your app next to your data, and the connection between them stops being your problem. It becomes the platform's job.