6 posts tagged with "app-hosting"

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.