Scaling and Health

Vertical scaling

Change an app's CPU and memory by moving it to another compute tier:

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

The app moves through PendingModification before returning to Running. Storage size is not changed by a scale operation.

Hot vs cold resize

Direction	Method	Downtime
Up (e.g. tier-2 to tier-4)	Hot resize: plan changes on the running VM, CPU and memory hotplugged.	None. A tier-2 to tier-4 resize typically completes in under 10 seconds with the app reachable throughout.
Down (e.g. tier-4 to tier-2)	Cold resize: VM restarts on the smaller plan.	Brief outage while the VM reboots.

The app's floating IP persists across reboots via a boot-time systemd unit, so a cold resize does not change the app's address.

Prefer tier-2, tier-4, and tier-6 for clean resizes. Tiers whose core and memory combination does not map cleanly to a standard cloud plan (tier-1, tier-3, tier-5) may overshoot cores on resize.

Health checks

Health checks serve two purposes:

1. Deploy gate. During a blue/green redeploy, the platform probes the new container on health_check_path before cutting traffic over. A container that never goes healthy fails the deploy; the previous container keeps serving.
2. Availability alerts. The agent continuously monitors the running container and reports availability metrics. See Alerts below.

Configure the probe in app_config:

Field	Default	Description
health_check_path	/	HTTP path probed on the container's own port. Must return 2xx.
health_check_interval_seconds	2	Seconds between probe attempts during a deploy.
health_check_timeout_seconds	120	Maximum seconds to wait for the container to become healthy before the deploy fails.
health_check_healthy_threshold	1	Consecutive 2xx responses required before the deploy cuts traffic over.

The probe runs on the VM loopback against the container port. It does not depend on public DNS or TLS.

Restart

Restart the app container without a full redeploy:

curl -u "$USER:$PASS" -X POST \
  https://api.foundrydb.com/app-services/{id}/restart

Returns 202 Accepted with a task_id. The container is restarted by the systemd Quadlet unit. This is distinct from a blue/green redeploy: a restart stops and restarts the running container in place, so there is a brief interruption.

Alerts

App VMs report CPU, memory, and storage metrics, which the platform's alert rules evaluate the same way as database services. Two additional availability alerts fire for apps:

Alert	Condition	Severity
App Down	The active container unit has not been running for 3 minutes. The 3-minute tolerance absorbs the brief blip of a blue/green rollout or a restart.	Critical
App Restart Loop	The container has restarted more than 2 times (warning) or more than 5 times (critical) since the last report, indicating a crash loop rather than a one-off restart.	Warning / Critical

Alerts appear on the Alerts tab of the app detail page in the dashboard, where you can acknowledge and resolve them.