4 posts tagged with "networking"

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.

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.

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.

Single-zone high availability is wonderful right up until the zone itself is the thing that breaks. A blown rack, a batched datacenter maintenance window, a regional routing incident, and every replica you so carefully provisioned next to your primary goes dark at the exact same moment. Today that stops being your problem to solve by hand. FoundryDB v0.8.0 ships cross-zone clusters: one managed database, spread across three zones, privately peered, with streaming replication that stays on the cloud backbone and never crosses the public internet.

This is the database property you always wanted and never wanted to build yourself. You ask for three zones, and you get a primary in one, replicas in the other two, a private peering mesh wiring them together, and two DNS records that already point at the right nodes. No second cluster to babysit. No VPN to watch. No 3am page because a replication slot filled up while you were asleep.