Runtime, Scale, Rollout, Health, and Network Profiles

Fields and defaults for runtime, scaling, rollout, health-check, and network profiles.

Stable identifier

A Resource owns persistent Runtime, Scale, Rollout, Health, and Network Profiles. They belong to the Resource itself, not to any single deployment’s temporary parameters — saving a profile does not immediately restart a running workload, it only affects the planning input used by future deployments.

Runtime Profile

Describes how to build and start the app.

Field	Description	Default
`strategy`	`auto` / `static` / Docker/OCI, and other runtime strategies	Attempts auto-detection
Install / Build commands	Dependency install and build commands	Derived from detection, or must be provided explicitly
Start command / image entrypoint	Process or container entrypoint to start	Derived from detection, or must be provided explicitly
Publish directory	Static site publish directory	No default; required under the static strategy

appaloft resource configure-runtime res_web \
  --strategy static \
  --build-command "bun run build" \
  --publish-directory dist

Scale and Rollout Profiles

resources.configure-scale stores replicas, CPU/memory requests and limits, plus optional HPA minimum/maximum replicas and a CPU target. resources.configure-rollout stores recreate, rolling, or canary intent. A target adapter must validate capability before any workload mutation; unsupported HPA metrics or canary promotion proof fails explicitly without silent fallback.

resources.show reads both profiles back. Kubernetes supports fixed replicas, resource budgets, HPA, recreate, rolling, and staged canary for one health-checked Traefik workload. Canary preserves the stable runtime, refreshes stable endpoints, applies and reads back each weight, then waits for external route identity convergence; any failed step cleans only the candidate. Service-graph canary, missing metrics/EndpointSlice/Traefik CRDs, or an unprovable public route fail explicitly without fallback.

Health Profile

Decides how the Verify phase determines whether the app is usable — it should match the real access path, not just check whether a process exists.

Field	Description	Default
Check type	Mainly HTTP today	Falls back to a weaker process-liveness check when unconfigured
Path	For example `/health`	No default
Expected status code	For example `200`	`200`
interval / timeout / retries / start period	Check frequency and tolerance window	See the example defaults below

appaloft resource configure-health res_web \
  --path /health \
  --method GET \
  --expected-status 200 \
  --interval 5 \
  --timeout 5 \
  --retries 10 \
  --start-period 15

# Reset to no custom health policy (doesn't affect runtime commands or network config)
appaloft resource reset-health res_web

Network Profile

Describes the app’s listening port, protocol, and proxy target — answering “where should the proxy forward requests.” Binding a custom domain is a separate Access configuration and is not part of this profile.

Field	Description	Default
Internal listening port	The port the app actually listens on inside the container	Fixed at `80` for static deployments; must be configured explicitly for SSR/HTTP services
Protocol	Mainly HTTP today	`http`
Exposure mode	Whether it needs a reverse proxy to be reached externally	`reverse-proxy`

appaloft resource configure-network res_web \
  --internal-port 3000 \
  --upstream-protocol http \
  --exposure-mode reverse-proxy

Error and recovery hints: Profile drift

Profile drift means the Profile currently saved on the Resource, the Profile in the repository’s config file, and the Profile in the most recent deployment snapshot disagree with each other — typically it happens after a resource already exists and part of it gets edited separately from repository config, a GitHub Action, CLI arguments, or the Web console.

Troubleshooting steps:

Run appaloft resource show res_web --json to view the structured diagnostics and identify which section (source / runtime / network / health / access) is inconsistent.
Follow the diagnostics to run the matching configure-source / configure-runtime / configure-network / configure-health command.
Trigger a new deployment after updating — historical deployment snapshots are never retroactively modified.

Secrets and configuration values are always masked in diagnostics and logs; when troubleshooting, rely only on the key, scope, and suggested command — never try to recover the plaintext value.

Example

A full health-check configuration response looks like:

GET /api/resources/res_web/health-profilejson

{
  "type": "http",
  "path": "/health",
  "expectedStatus": 200,
  "intervalSeconds": 5,
  "timeoutSeconds": 5,
  "retries": 10,
  "startPeriodSeconds": 15
}