Skip to main content

Safer Deploys, Instant Rollback, and Live Scaling for FoundryDB Apps

· 5 min read
FoundryDB Team
FoundryDB Team
Engineering @ FoundryDB

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.

Deploy history and one-click rollback​

Every time you deploy, the platform records an immutable revision: the image reference, the environment variables, the domains, and the registry username in effect at that moment. Revisions accumulate, so the deploy history of an app is a full, ordered record of what actually ran in production, not a guess reconstructed from your CI logs.

curl -u "$USER:$PASS" https://api.foundrydb.com/app-services/$APP_ID/deployments

When a deploy breaks production, you do not need to find the old image tag, dig the right environment variables out of a chat thread, and reassemble the previous config by hand. You pick the revision that was last known good and roll back to it.

curl -u "$USER:$PASS" -X POST https://api.foundrydb.com/app-services/$APP_ID/rollback \
  -H 'Content-Type: application/json' \
  -d '{ "deployment_id": "DEPLOYMENT_ID" }'

A rollback is a deploy like any other: it goes through the same blue/green flip, so the old container keeps serving until the rolled-back container is up. In the dashboard it is one click on the revision you want. "The last deploy broke prod, get me back" is now a single action instead of an archaeology project.

Configurable health checks and safer deploys​

The launch blue/green flip waited for the new container to start. Started is not the same as ready. A container can come up, bind its port, and still be failing every request because a migration has not run or a downstream dependency is missing. Shipping that image used to mean cutting traffic over to a black hole.

You can now set a health check on the app config: a readiness path, a healthy threshold, and a timeout.

curl -u "$USER:$PASS" -X PATCH https://api.foundrydb.com/app-services/$APP_ID \
  -H 'Content-Type: application/json' \
  -d '{
    "app_config": {
      "health_check_path": "/healthz",
      "health_check_healthy_threshold": 3,
      "health_check_timeout_seconds": 60
    }
  }'

Now the blue/green rollout only cuts traffic over once the new container returns the configured number of consecutive 2xx responses on the readiness path. If the new container never reaches the healthy threshold within the timeout, the deploy fails and the old container keeps serving. A broken image does not become a broken site. It becomes a failed deploy you see immediately, with production untouched.

This composes with rollback exactly the way you would want. A bad deploy that does not pass its health check never takes traffic in the first place, and if a regression slips through anyway, the previous revision is one request away.

Zero-downtime vertical scaling​

When an app outgrows its plan, you change the compute plan in one request.

curl -u "$USER:$PASS" -X POST https://api.foundrydb.com/app-services/$APP_ID/scale \
  -H 'Content-Type: application/json' \
  -d '{ "plan_name": "tier-4" }'

Scaling up is a live hot resize of the underlying VM with no reboot. The container keeps running, the ingress keeps serving, and the new CPU and memory are available without a restart. On a staging run, a tier-2 to tier-4 scale-up completed in about nine seconds with the app reachable over HTTPS the entire time, including during the resize itself.

No reboot means no cold start, no dropped connections, and no maintenance window. You scale into a traffic spike instead of bracing for one.

App alerts on the detail page​

An app you cannot see is an app you find out about from your users. CPU and memory alerts now surface on the Alerts tab of the app detail page, so a container pinning its CPU or creeping toward its memory ceiling is visible where you are already looking, alongside the deploy history, the attached databases, and the metrics.

This is the signal that tells you when to reach for the scale request above. Watch the app, see the pressure build, scale with no reboot, and keep serving. The loop closes inside the dashboard.

Putting it together​

These four features are a single story about operating an app, not just deploying one. You ship behind a health check, so a broken image fails the deploy instead of taking traffic. If something slips through, you roll back to a known-good revision in one request. When load climbs, the Alerts tab tells you, and you scale up live with no reboot. Each deploy you make is recorded, so you always know exactly what is running and exactly what to go back to.

Deploying was the easy part. Operating it just got a lot calmer.