App Hosting Is Here: Deploy Your App Next to Your Data

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.

What you can build now

Picture the things that used to require a second platform and an afternoon of plumbing. A REST API that reads from PostgreSQL and OpenSearch, both on a private network, both reachable the instant the container boots. A background worker that streams rows from one database into another. A public-facing service at your own clean foundrydb.com hostname with a real certificate, no ingress controller to configure, no cert to request by hand. All of it next to the data it actually uses, all of it provisioned with a single API call.

An app service runs a single public or private OCI container image on a dedicated VM. It is reachable at https://NAME.foundrydb.com with a platform-issued certificate, and it can be attached to up to five of your managed databases. You POST a definition, then poll until the service reaches Running. That is the whole surface. No ingress controller, no certificate request, no firewall rule to hand-edit on the database side, no connection string to copy into your app's secrets. The platform does each of those steps and drives them to completion.

The hero: attach a database, and the network just appears

Here is what makes App Hosting different from a container you rent on the side. Attach a database, and the platform does three things in order, every one of them the kind of work you would otherwise do by hand and get wrong at least once.

First, it peers the networks. The app's private SDN is peered to each attached database's private network, the same private-network primitive that powers replication and pipelines across the platform. App-to-database traffic stays on the cloud provider's backbone and never touches the public internet.

Second, it opens the path on the database side. The database firewall admits the app's subnet, and for PostgreSQL the platform adds the matching pg_hba.conf entry. The opening is scoped to the app's subnet, not the world.

Third, it injects credentials as environment variables. Your container starts with the connection details already in its environment. You never copy a password.

The variables follow a predictable scheme, one set per attached database, prefixed by its name: MDB_ORDERS_HOST, MDB_ORDERS_PORT, MDB_ORDERS_USER, MDB_ORDERS_PASSWORD, MDB_ORDERS_DATABASE. When exactly one database is attached, you also get a ready-to-use DATABASE_URL, so the common case is a single line of config. The host is always the primary's private SDN address, so the shortest path between your app and your data is also the only path. And if a database fails over, the attachment keeps resolving to the current primary. You do not chase it.

A runtime built to stay out of your way

Each app gets its own VM. On that VM, one container runs under Podman, managed by a systemd Quadlet unit, so it is a real, supervised system service rather than a daemon nobody is watching. In front of it sits a Caddy ingress that terminates TLS and forwards to your container's port. The certificate for NAME.foundrydb.com is issued over DNS-01 before your app ever serves a request.

One container per VM is a deliberate choice, and it pays you back. The failure domain stays small. The resource accounting stays honest: you are billed by the compute plan, nothing fuzzy. Apps are stateless beyond their attached databases, so there is no backup storage to pay for and no volume lifecycle to reason about.

Blue/green deploys that never take you down

Shipping a new image or changing an environment variable does not mean an outage. The platform pulls the new image and starts the new container alongside the old one on the same VM, waits for it to come up, then flips the ingress. If the new container fails to start, the ingress never flips and the old container keeps serving. A broken redeploy becomes a non-event for your users instead of a 2am page for you.

Restart, logs, and delete round out the lifecycle. Deleting an app tears down everything the platform built for it: the container, the ingress, the certificates, the DNS records, the floating IP, the attachment peerings, and the VM. Nothing is left behind to surprise you on next month's bill.

We proved it on something real

We did not want to ship this on a hello-world. The validation run is a single app, deployed from a private image, attached to both a PostgreSQL service and an OpenSearch service at the same time. It runs a continuous pipeline: generate order rows into PostgreSQL, stream them into OpenSearch, with a live dashboard showing both sides.

It works. On a real staging run the pipeline reached pg_rows = os_docs = flowed = 48 and kept climbing, both databases reachable over the private SDN, neither connection ever touching the public internet. The app read its PostgreSQL credentials from MDB_* variables it never had to be told about, talked to OpenSearch on a private address, and served its dashboard over HTTPS at its foundrydb.com hostname. One colocated app, privately networked to more than one managed database at once, with credentials, firewall, peering, and TLS all handled by the platform.

This is the foundation for what comes next

App Hosting is exciting on its own. It is also the start of something bigger. Custom domains and private registry credentials shipped right alongside this launch, so you can serve your app on your own hostnames with automatic certificates and pull private images with write-only registry credentials. After that, the direction we are most excited about is more than one app talking to a shared set of databases, and tighter integration with the data pipelines that already run between your services. To be honest about where the line is today: that next chapter is on the roadmap, not yet in your hands. We will say more when it is real.

For today, your app and your data finally live in the same place, on the same private network, under one bill, in Europe.

Deploy your first app, attach a database, and redeploy without flinching, from the REST API, the SDKs, or your AI assistant through the MCP server. Your app and your data have been living apart long enough. Go build something with them.