Apps

Immutable app identifier. Unique among the authenticated organization's live apps: it cannot be changed after creation, and it becomes available again once the app it named reaches deleted.

Mutable display name. Must start and end with a non-whitespace character: it is what the console renders and what sort=name orders on, and it is not required to be unique. Interior spaces are allowed ("Sentiment Analysis"). Leading or trailing whitespace is rejected, because a padded name is indistinguishable from its trimmed form in the console and breaks a name-confirm delete.

Live worker configuration. Updated via PATCH /apps/{appId}.

Whether the app's workload can serve, and why. reason covers more than capacity: a workload that is missing or being torn down also reports state: unavailable. Only capacity_below_floor and demand_unserved are the platform being short of workers, and only those refuse an invocation with capacity-unavailable. The others are refused with the plain service-unavailable, because retrying does not bring a removed workload back. Populated on the app reads only: GET /v1/apps/{appId} and GET /v1/apps. Every other response that carries an app omits it, because the verdict is observed from the cluster rather than changed by the request: read the app again after a mutation. Within those two reads it is absent for any of four reasons: the platform has not observed the app yet, which is normal for one that has never deployed. The app is in a lifecycle state whose verdict is not published, such as stopped, failed, or one that is draining. The verdict could not be read on this request, or the stored verdict carries a value this version of the API does not recognise. The four are not distinguished, so absence is never a claim that the app is healthy. The first two are stable, the third clears by itself, and the last persists until the API is upgraded.

The worker ceiling the last deploy actually applied, reduced where the organization's credit balance did not back the whole range. The autoscaler cannot grow past it.

It describes what was applied, not what is configured now, and the two can differ. It is taken from the maxWorkers of the version that was deployed, so deploying an older version applies that version's ceiling, and a later PATCH of configuration.maxWorkers does not change it until the next deploy. Read it beside configuration.maxWorkers rather than as a bound on it.

null means nothing has been applied yet. It is recalculated on every deploy. A credit top-up also recalculates a reduced ceiling and restores the funded range, with no redeploy.

Observed state for one app at calculatedAt. Desired worker scale remains in configuration. Worker and GPU counts are always present. Traffic, duration, and queue fields are omitted when their backing data is unavailable.

Secrets attached to this app, including any env-var name override. Populated on single-app responses. List of apps returns an empty array to avoid an N+1. Use /apps/{appId}/secrets to page the set.

Plain-text environment variables for this app. Populated on single-app responses (get, update, stop, resume, delete, deploy, favorite). List of apps returns an empty array to avoid an N+1 per page row. Use the /environment-variables endpoints to page the set.

Where the app is in its lifecycle. initializing is building or rolling out its first version. active is deployed and accepting invocations. stopping is draining its workers. stopped holds no workers and accepts none. deleting and deleted are removal. failed is a rollout the platform could not complete. A failed app accepts no invocations. Recover it with POST /v1/apps/{appId}/deploy when it has a ready version, or with a new appSource through PATCH /v1/apps/{appId}. Lifecycle is not health. active says the app is deployed and taking work, not that workers exist to run it: an app whose workers the platform cannot currently place stays active. Read health for that.

Whether the authenticated organization has favorited this app. Favorited apps sort ahead of non-favorited apps. Toggled via PUT/DELETE /v1/apps/{appId}/favorite.

Current deployed version. Null until the first version is successfully deployed.

GPU is the only supported compute type. Omitting the field selects GPU. CPU workloads are not supported. A request that names cpu is rejected with 422 before a build or deploy starts.

GPU type the workers run on. Required: omitting it (or sending null) is a 422 before a build or deploy starts, because a GPU app with no type is unpinned and the deployer would render NVIDIA defaults. Must match an id returned by GET /v1/gpu-types that currently has admitted capacity.

Secondary GPU type recorded for this app. It is validated and stored, but placement does not yet substitute it, so it is not failover you can rely on today. Omit, send JSON null, or send an empty string for no fallback. Forms bind an unselected dropdown as "", which is not a GpuTypeId. A non-empty value must be an active catalog code. Unlike gpuType this is an existence check only: it does not require admitted capacity, so the code may not appear in the customer GET /v1/gpu-types list.

GPUs granted to one worker pod. A worker holds its GPUs as one group the cluster grants indivisibly, so the count is one of the advertised group sizes rather than any number in a range. The value must also be a group size admitted by the cluster backing the chosen gpuType: a count above 1 that cluster does not grant is rejected with a 422 naming /configuration/gpusPerWorker, since the pod could never be scheduled. A value above 1 requires an image built after the multi-GPU worker entrypoint. Older images serve a single rank while holding every granted GPU.

Idle workers held above current demand. Omit, or send null or 0, for no buffer. Must be lower than maxWorkers. The buffer applies only while the queue is non-empty, so it does not stop an idle app scaling to minWorkers. A buffer below about a tenth of current demand is not added while demand holds steady. availableWorkersPct is not subject to that.

Idle workers held above current demand, as a percentage of that demand, rounded up. Omit, or send null or 0, for no buffer. When both buffers are set the larger of the two applies. The buffer applies only while the queue is non-empty, so it does not stop an idle app scaling to minWorkers.

How long the sidecar waits on one forwarded container request. Container-only. Omit on a container app to take 60s. A code app may still send or omit this field: omit stores 600s for the console, and neither value is applied to MLflow reads, which keep the platform ceiling. A later container.yaml deploy overwrites the live value with that document's timeouts.requestSeconds. Bounds the worker, not the synchronous HTTP wait.

How long readiness has before the pod is failed. Omit to take the source default: 300s for a container app, 2400s for a code app (the probe budget a code worker already had). A later container.yaml deploy overwrites the live value with that document's timeouts.startupSeconds.

Selects the version creation path. code submits customer source code to the Image Build Service. container submits a wrapper Dockerfile and container.yaml for Runware to build into a hosted image.

Organization-scoped secret name. The shape matches EnvironmentVariableName and the secrets.name / deployment_secrets.env_var_name column CHECKs, one rule for the contract and the schema, because attached secrets are intended to be injected as environment variables once ADR-019 in-pod unseal lands. Names the platform sets on the serving container (RUNTIME, DISABLE_NGINX, MLFLOW_MODELS_WORKERS, UVICORN_HOST) are rejected with 422: when injection exists, the deployer appends customer env after its own and kubelet resolves duplicates last-wins, so an accepted collision would silently replace a platform value. Same guard as plain environment variables. Enforced by the server (not expressible as a pattern here).

Environment variable name the secret is injected as. Omit or null to use secretName. The server resolves and stores the final name. Same reserved-name rules as SecretName (422 if reserved). The resolved name must also not collide with a plain environment variable key on this app (422).

Absolute path exposed inside the sandboxed application. The path is the volume's stable identity and is mirrored below the app's node-local data directory. Root, duplicate, and overlapping paths are rejected. Each path component (the text between / separators) is at most 255 bytes, the filesystem NAME_MAX the mirrored node directory must satisfy.

Immutable app identifier. Unique among the authenticated organization's live apps: it cannot be changed after creation, and it becomes available again once the app it named reaches deleted.

Worker compute class. GPU is the only supported value. CPU workloads are not supported.

Preferred GPU type. Absent (or null) only on historical apps created before a GPU type was required.

Secondary GPU type recorded for this app. It is validated and stored, but placement does not yet substitute it: a worker that cannot get gpuType waits for that type rather than starting on this one. Do not rely on it as failover.

GPUs granted to one worker pod. Create and update accept only the group sizes the cluster grants indivisibly, since a worker holds its GPUs as one such group. Historical apps may contain another value.

Floor for scale-down. 0 = scale to zero.

Idle workers held above current demand, so a burst does not wait for a cold start. Null or 0 means no buffer. The buffer applies only while the queue is non-empty: an idle app still scales to minWorkers. A buffer below about a tenth of current demand is not added while demand holds steady. availableWorkersPct is not subject to that.

Idle workers held above current demand, as a percentage of that demand, rounded up. Null or 0 means no buffer. When both buffers are set the larger of the two applies. The buffer applies only while the queue is non-empty: an idle app still scales to minWorkers.

Seconds a worker can sit idle before the Scaler removes it.

Cooldown between consecutive scaling decisions.

How long the sidecar waits on one forwarded container request. Container-only: a code app keeps the platform MLflow read ceiling, so this field is stored and returned but is not applied to those reads. Bounds the worker, not the synchronous HTTP wait: invoke-sync still answers 504 at the platform deadline so the caller can poll. A later container.yaml deploy overwrites this with that document's timeouts.requestSeconds.

How long readiness has before the pod is failed. Rendered as the startup probe budget and the sidecar's own startup gate. A later container.yaml deploy overwrites this with that document's timeouts.startupSeconds.

Whether the app's workload can serve. healthy can serve. degraded can serve with less capacity than it asks for. unavailable has nothing able to serve. Read AppHealthReason for the cause. This is a report on the workload, not an admission rule. Only an active app is refused on it: an initializing app that already has a version to route to accepts invocations while it reports unavailable, which is the ordinary case during a first deploy, and a draining app is not gated on health at all. Do not read this field as whether the next invocation will be accepted.

Why the app holds its current health state. capacity_below_floor and demand_unserved are the two shapes of capacity exhaustion, and they differ in what the app asked for. capacity_below_floor means the app keeps a warm floor above zero and has fewer workers able to serve than that floor. demand_unserved means the app scales to zero, so it has no floor to be short of, and work is waiting on its queue with nothing running it. They behave differently during a cold start. An app waking from zero is given a grace period before it is called starved, so an ordinary wake-up is not reported as a fault. An app with a warm floor gets no such grace: it reports capacity_below_floor from the moment its workload is applied until its first worker is ready, so a normal first deploy reports it for the whole of its cold start. Use since to tell the two apart. A cold start clears within the app's startup time, and a real shortage does not. Neither names whose fault the shortfall is, and neither is a statement about charging. A worker the platform never placed holds no GPU and costs nothing, but the same two reasons also cover workers that were placed and cannot serve, and those hold a GPU. Some of those states are charged for and some are not: a container that crash-loops or one still loading is charged, while one still pulling its image is not. Read the app's workers to tell the cases apart. autoscaler_unhealthy means the autoscaler cannot act on the workload, so the app will not grow with demand. workload_present accompanies a healthy app. workload_terminating and workload_missing are a workload being removed or already gone, which a stop or a delete explains.

When the app entered this state. It moves only when state changes, so it answers how long the condition has held, the figure to quote when asking how long an app has been unable to serve.

When the platform last looked. It is rewritten on every observation, so it reports the freshness of the verdict and not the age of the condition. A value far in the past means nothing has observed the app recently.

Non-terminal workers (status other than stopped) on this app's active version. Pending workers count because they appear in the active-version workers list before Kubernetes assigns a GPU. Outgoing-version workers are excluded because the default workers list omits them. A deleted app reports zero.

Sum of gpuCount across those workers. A pending worker contributes zero until Kubernetes schedules it onto a node.

When this runtime snapshot was read from the database.

Requests served by this app in the last 24 hours. Omitted until available.

Error ratio (4xx + 5xx over requests) for this app in the last 24 hours, in 0–1. Omitted when metrics cannot be read or when the app had no requests in the window.

Mean inference request duration in seconds over the last 24 hours (all requests, the duration histogram has no status class). Omitted when metrics cannot be read, when the app had no requests, or when the duration series has no samples for the app in the window.

Ready plus unacknowledged messages on this app's live inference queue. Omitted when the app is not live or the gauge cannot be read. Zero when the queue is live and empty.

Organization-scoped secret name. The shape matches EnvironmentVariableName and the secrets.name / deployment_secrets.env_var_name column CHECKs, one rule for the contract and the schema, because attached secrets are intended to be injected as environment variables once ADR-019 in-pod unseal lands. Names the platform sets on the serving container (RUNTIME, DISABLE_NGINX, MLFLOW_MODELS_WORKERS, UVICORN_HOST) are rejected with 422: when injection exists, the deployer appends customer env after its own and kubelet resolves duplicates last-wins, so an accepted collision would silently replace a platform value. Same guard as plain environment variables. Enforced by the server (not expressible as a pattern here).

Kind of secret. Only the environment-variable variant (generic) is supported. Image-pull (registry) credentials are consumed by the kubelet before any container starts, so they cannot use the in-pod unseal path (ADR-019) and await their own decision.

Optional opaque metadata associated with the secret.

Resolved environment variable name when it differs from name. Omitted when the secret name is used. Same reserved-name rules as SecretName when set.

Immutable app identifier. Unique among the authenticated organization's live apps: it cannot be changed after creation, and it becomes available again once the app it named reaches deleted.

POSIX-style environment variable name. Letters, digits, and underscore. Must start with a letter or underscore. Matched by the deployment_configs column CHECK so a valid-by-contract request cannot 500 at INSERT.

Immutable app identifier. Unique among the authenticated organization's live apps: it cannot be changed after creation, and it becomes available again once the app it named reaches deleted.

Worker compute class. GPU is the only supported value. CPU workloads are not supported.

Preferred GPU type. Absent (or null) only on historical apps created before a GPU type was required.

Secondary GPU type recorded for this app. It is validated and stored, but placement does not yet substitute it: a worker that cannot get gpuType waits for that type rather than starting on this one. Do not rely on it as failover.

GPUs granted to one worker pod. Create and update accept only the group sizes the cluster grants indivisibly, since a worker holds its GPUs as one such group. Historical apps may contain another value.

Floor for scale-down. 0 = scale to zero.

Idle workers held above current demand, so a burst does not wait for a cold start. Null or 0 means no buffer. The buffer applies only while the queue is non-empty: an idle app still scales to minWorkers. A buffer below about a tenth of current demand is not added while demand holds steady. availableWorkersPct is not subject to that.

Idle workers held above current demand, as a percentage of that demand, rounded up. Null or 0 means no buffer. When both buffers are set the larger of the two applies. The buffer applies only while the queue is non-empty: an idle app still scales to minWorkers.

Seconds a worker can sit idle before the Scaler removes it.

Cooldown between consecutive scaling decisions.

How long the sidecar waits on one forwarded container request. Container-only: a code app keeps the platform MLflow read ceiling, so this field is stored and returned but is not applied to those reads. Bounds the worker, not the synchronous HTTP wait: invoke-sync still answers 504 at the platform deadline so the caller can poll. A later container.yaml deploy overwrites this with that document's timeouts.requestSeconds.

How long readiness has before the pod is failed. Rendered as the startup probe budget and the sidecar's own startup gate. A later container.yaml deploy overwrites this with that document's timeouts.startupSeconds.

Whether the app's workload can serve. healthy can serve. degraded can serve with less capacity than it asks for. unavailable has nothing able to serve. Read AppHealthReason for the cause. This is a report on the workload, not an admission rule. Only an active app is refused on it: an initializing app that already has a version to route to accepts invocations while it reports unavailable, which is the ordinary case during a first deploy, and a draining app is not gated on health at all. Do not read this field as whether the next invocation will be accepted.

Why the app holds its current health state. capacity_below_floor and demand_unserved are the two shapes of capacity exhaustion, and they differ in what the app asked for. capacity_below_floor means the app keeps a warm floor above zero and has fewer workers able to serve than that floor. demand_unserved means the app scales to zero, so it has no floor to be short of, and work is waiting on its queue with nothing running it. They behave differently during a cold start. An app waking from zero is given a grace period before it is called starved, so an ordinary wake-up is not reported as a fault. An app with a warm floor gets no such grace: it reports capacity_below_floor from the moment its workload is applied until its first worker is ready, so a normal first deploy reports it for the whole of its cold start. Use since to tell the two apart. A cold start clears within the app's startup time, and a real shortage does not. Neither names whose fault the shortfall is, and neither is a statement about charging. A worker the platform never placed holds no GPU and costs nothing, but the same two reasons also cover workers that were placed and cannot serve, and those hold a GPU. Some of those states are charged for and some are not: a container that crash-loops or one still loading is charged, while one still pulling its image is not. Read the app's workers to tell the cases apart. autoscaler_unhealthy means the autoscaler cannot act on the workload, so the app will not grow with demand. workload_present accompanies a healthy app. workload_terminating and workload_missing are a workload being removed or already gone, which a stop or a delete explains.

When the app entered this state. It moves only when state changes, so it answers how long the condition has held, the figure to quote when asking how long an app has been unable to serve.

When the platform last looked. It is rewritten on every observation, so it reports the freshness of the verdict and not the age of the condition. A value far in the past means nothing has observed the app recently.

Non-terminal workers (status other than stopped) on this app's active version. Pending workers count because they appear in the active-version workers list before Kubernetes assigns a GPU. Outgoing-version workers are excluded because the default workers list omits them. A deleted app reports zero.

Sum of gpuCount across those workers. A pending worker contributes zero until Kubernetes schedules it onto a node.

When this runtime snapshot was read from the database.

Requests served by this app in the last 24 hours. Omitted until available.

Error ratio (4xx + 5xx over requests) for this app in the last 24 hours, in 0–1. Omitted when metrics cannot be read or when the app had no requests in the window.

Mean inference request duration in seconds over the last 24 hours (all requests, the duration histogram has no status class). Omitted when metrics cannot be read, when the app had no requests, or when the duration series has no samples for the app in the window.

Ready plus unacknowledged messages on this app's live inference queue. Omitted when the app is not live or the gauge cannot be read. Zero when the queue is live and empty.

Organization-scoped secret name. The shape matches EnvironmentVariableName and the secrets.name / deployment_secrets.env_var_name column CHECKs, one rule for the contract and the schema, because attached secrets are intended to be injected as environment variables once ADR-019 in-pod unseal lands. Names the platform sets on the serving container (RUNTIME, DISABLE_NGINX, MLFLOW_MODELS_WORKERS, UVICORN_HOST) are rejected with 422: when injection exists, the deployer appends customer env after its own and kubelet resolves duplicates last-wins, so an accepted collision would silently replace a platform value. Same guard as plain environment variables. Enforced by the server (not expressible as a pattern here).

Kind of secret. Only the environment-variable variant (generic) is supported. Image-pull (registry) credentials are consumed by the kubelet before any container starts, so they cannot use the in-pod unseal path (ADR-019) and await their own decision.

Optional opaque metadata associated with the secret.

Resolved environment variable name when it differs from name. Omitted when the secret name is used. Same reserved-name rules as SecretName when set.

Immutable app identifier. Unique among the authenticated organization's live apps: it cannot be changed after creation, and it becomes available again once the app it named reaches deleted.

POSIX-style environment variable name. Letters, digits, and underscore. Must start with a letter or underscore. Matched by the deployment_configs column CHECK so a valid-by-contract request cannot 500 at INSERT.

Preferred GPU type. Omit to leave unchanged. Rejected with a 422 when no capacity is currently offered for the type (it does not appear in GET /v1/gpu-types).

Secondary GPU type. Omit to leave unchanged. Send an empty string to clear. Forms bind an unselected dropdown as "". JSON null is rejected: this field is not nullable, so a client that meant to clear must send "" rather than null. A non-empty value must be an active catalog code. Unlike gpuType this is an existence check only: it does not require admitted capacity, so the code may not appear in the customer GET /v1/gpu-types list.

GPUs granted to one worker pod. A worker holds its GPUs as one group the cluster grants indivisibly, so the count is one of the advertised group sizes rather than any number in a range. The value must also be a group size admitted by the cluster backing the chosen gpuType: a count above 1 that cluster does not grant is rejected with a 422 naming /configuration/gpusPerWorker, since the pod could never be scheduled. A value above 1 requires an image built after the multi-GPU worker entrypoint. Older images serve a single rank while holding every granted GPU.

Idle workers held above current demand. Omit to leave unchanged. Send 0 to remove the buffer. Null is refused, because omitting a field and clearing it mean different things here. Must be lower than the resolved maxWorkers.

Idle workers held above current demand, as a percentage of that demand, rounded up. Omit to leave unchanged. Send 0 to remove the buffer. Null is refused, because omitting a field and clearing it mean different things here.

How long the sidecar waits on one forwarded container request. Omit to leave unchanged. Applied to container workers only. A code app stores the new value but keeps the platform MLflow read ceiling.

Selects the version creation path. code submits customer source code to the Image Build Service. container submits a wrapper Dockerfile and container.yaml for Runware to build into a hosted image.

Organization-scoped secret name. The shape matches EnvironmentVariableName and the secrets.name / deployment_secrets.env_var_name column CHECKs, one rule for the contract and the schema, because attached secrets are intended to be injected as environment variables once ADR-019 in-pod unseal lands. Names the platform sets on the serving container (RUNTIME, DISABLE_NGINX, MLFLOW_MODELS_WORKERS, UVICORN_HOST) are rejected with 422: when injection exists, the deployer appends customer env after its own and kubelet resolves duplicates last-wins, so an accepted collision would silently replace a platform value. Same guard as plain environment variables. Enforced by the server (not expressible as a pattern here).

Environment variable name the secret is injected as. Omit or null to use secretName. The server resolves and stores the final name. Same reserved-name rules as SecretName (422 if reserved). The resolved name must also not collide with a plain environment variable key on this app (422).

Immutable app identifier. Unique among the authenticated organization's live apps: it cannot be changed after creation, and it becomes available again once the app it named reaches deleted.

Worker compute class. GPU is the only supported value. CPU workloads are not supported.

Preferred GPU type. Absent (or null) only on historical apps created before a GPU type was required.

Secondary GPU type recorded for this app. It is validated and stored, but placement does not yet substitute it: a worker that cannot get gpuType waits for that type rather than starting on this one. Do not rely on it as failover.

GPUs granted to one worker pod. Create and update accept only the group sizes the cluster grants indivisibly, since a worker holds its GPUs as one such group. Historical apps may contain another value.

Floor for scale-down. 0 = scale to zero.

Idle workers held above current demand, so a burst does not wait for a cold start. Null or 0 means no buffer. The buffer applies only while the queue is non-empty: an idle app still scales to minWorkers. A buffer below about a tenth of current demand is not added while demand holds steady. availableWorkersPct is not subject to that.

Idle workers held above current demand, as a percentage of that demand, rounded up. Null or 0 means no buffer. When both buffers are set the larger of the two applies. The buffer applies only while the queue is non-empty: an idle app still scales to minWorkers.

Seconds a worker can sit idle before the Scaler removes it.

Cooldown between consecutive scaling decisions.

How long the sidecar waits on one forwarded container request. Container-only: a code app keeps the platform MLflow read ceiling, so this field is stored and returned but is not applied to those reads. Bounds the worker, not the synchronous HTTP wait: invoke-sync still answers 504 at the platform deadline so the caller can poll. A later container.yaml deploy overwrites this with that document's timeouts.requestSeconds.

How long readiness has before the pod is failed. Rendered as the startup probe budget and the sidecar's own startup gate. A later container.yaml deploy overwrites this with that document's timeouts.startupSeconds.

Whether the app's workload can serve. healthy can serve. degraded can serve with less capacity than it asks for. unavailable has nothing able to serve. Read AppHealthReason for the cause. This is a report on the workload, not an admission rule. Only an active app is refused on it: an initializing app that already has a version to route to accepts invocations while it reports unavailable, which is the ordinary case during a first deploy, and a draining app is not gated on health at all. Do not read this field as whether the next invocation will be accepted.

Why the app holds its current health state. capacity_below_floor and demand_unserved are the two shapes of capacity exhaustion, and they differ in what the app asked for. capacity_below_floor means the app keeps a warm floor above zero and has fewer workers able to serve than that floor. demand_unserved means the app scales to zero, so it has no floor to be short of, and work is waiting on its queue with nothing running it. They behave differently during a cold start. An app waking from zero is given a grace period before it is called starved, so an ordinary wake-up is not reported as a fault. An app with a warm floor gets no such grace: it reports capacity_below_floor from the moment its workload is applied until its first worker is ready, so a normal first deploy reports it for the whole of its cold start. Use since to tell the two apart. A cold start clears within the app's startup time, and a real shortage does not. Neither names whose fault the shortfall is, and neither is a statement about charging. A worker the platform never placed holds no GPU and costs nothing, but the same two reasons also cover workers that were placed and cannot serve, and those hold a GPU. Some of those states are charged for and some are not: a container that crash-loops or one still loading is charged, while one still pulling its image is not. Read the app's workers to tell the cases apart. autoscaler_unhealthy means the autoscaler cannot act on the workload, so the app will not grow with demand. workload_present accompanies a healthy app. workload_terminating and workload_missing are a workload being removed or already gone, which a stop or a delete explains.

When the app entered this state. It moves only when state changes, so it answers how long the condition has held, the figure to quote when asking how long an app has been unable to serve.

When the platform last looked. It is rewritten on every observation, so it reports the freshness of the verdict and not the age of the condition. A value far in the past means nothing has observed the app recently.

Non-terminal workers (status other than stopped) on this app's active version. Pending workers count because they appear in the active-version workers list before Kubernetes assigns a GPU. Outgoing-version workers are excluded because the default workers list omits them. A deleted app reports zero.

Sum of gpuCount across those workers. A pending worker contributes zero until Kubernetes schedules it onto a node.

When this runtime snapshot was read from the database.

Requests served by this app in the last 24 hours. Omitted until available.

Error ratio (4xx + 5xx over requests) for this app in the last 24 hours, in 0–1. Omitted when metrics cannot be read or when the app had no requests in the window.

Mean inference request duration in seconds over the last 24 hours (all requests, the duration histogram has no status class). Omitted when metrics cannot be read, when the app had no requests, or when the duration series has no samples for the app in the window.

Ready plus unacknowledged messages on this app's live inference queue. Omitted when the app is not live or the gauge cannot be read. Zero when the queue is live and empty.

Organization-scoped secret name. The shape matches EnvironmentVariableName and the secrets.name / deployment_secrets.env_var_name column CHECKs, one rule for the contract and the schema, because attached secrets are intended to be injected as environment variables once ADR-019 in-pod unseal lands. Names the platform sets on the serving container (RUNTIME, DISABLE_NGINX, MLFLOW_MODELS_WORKERS, UVICORN_HOST) are rejected with 422: when injection exists, the deployer appends customer env after its own and kubelet resolves duplicates last-wins, so an accepted collision would silently replace a platform value. Same guard as plain environment variables. Enforced by the server (not expressible as a pattern here).

Kind of secret. Only the environment-variable variant (generic) is supported. Image-pull (registry) credentials are consumed by the kubelet before any container starts, so they cannot use the in-pod unseal path (ADR-019) and await their own decision.

Optional opaque metadata associated with the secret.

Resolved environment variable name when it differs from name. Omitted when the secret name is used. Same reserved-name rules as SecretName when set.

Immutable app identifier. Unique among the authenticated organization's live apps: it cannot be changed after creation, and it becomes available again once the app it named reaches deleted.

POSIX-style environment variable name. Letters, digits, and underscore. Must start with a letter or underscore. Matched by the deployment_configs column CHECK so a valid-by-contract request cannot 500 at INSERT.

Immutable app identifier. Unique among the authenticated organization's live apps: it cannot be changed after creation, and it becomes available again once the app it named reaches deleted.

Worker compute class. GPU is the only supported value. CPU workloads are not supported.

Preferred GPU type. Absent (or null) only on historical apps created before a GPU type was required.

Secondary GPU type recorded for this app. It is validated and stored, but placement does not yet substitute it: a worker that cannot get gpuType waits for that type rather than starting on this one. Do not rely on it as failover.

GPUs granted to one worker pod. Create and update accept only the group sizes the cluster grants indivisibly, since a worker holds its GPUs as one such group. Historical apps may contain another value.

Floor for scale-down. 0 = scale to zero.

Idle workers held above current demand, so a burst does not wait for a cold start. Null or 0 means no buffer. The buffer applies only while the queue is non-empty: an idle app still scales to minWorkers. A buffer below about a tenth of current demand is not added while demand holds steady. availableWorkersPct is not subject to that.

Idle workers held above current demand, as a percentage of that demand, rounded up. Null or 0 means no buffer. When both buffers are set the larger of the two applies. The buffer applies only while the queue is non-empty: an idle app still scales to minWorkers.

Seconds a worker can sit idle before the Scaler removes it.

Cooldown between consecutive scaling decisions.

How long the sidecar waits on one forwarded container request. Container-only: a code app keeps the platform MLflow read ceiling, so this field is stored and returned but is not applied to those reads. Bounds the worker, not the synchronous HTTP wait: invoke-sync still answers 504 at the platform deadline so the caller can poll. A later container.yaml deploy overwrites this with that document's timeouts.requestSeconds.

How long readiness has before the pod is failed. Rendered as the startup probe budget and the sidecar's own startup gate. A later container.yaml deploy overwrites this with that document's timeouts.startupSeconds.

Whether the app's workload can serve. healthy can serve. degraded can serve with less capacity than it asks for. unavailable has nothing able to serve. Read AppHealthReason for the cause. This is a report on the workload, not an admission rule. Only an active app is refused on it: an initializing app that already has a version to route to accepts invocations while it reports unavailable, which is the ordinary case during a first deploy, and a draining app is not gated on health at all. Do not read this field as whether the next invocation will be accepted.

Why the app holds its current health state. capacity_below_floor and demand_unserved are the two shapes of capacity exhaustion, and they differ in what the app asked for. capacity_below_floor means the app keeps a warm floor above zero and has fewer workers able to serve than that floor. demand_unserved means the app scales to zero, so it has no floor to be short of, and work is waiting on its queue with nothing running it. They behave differently during a cold start. An app waking from zero is given a grace period before it is called starved, so an ordinary wake-up is not reported as a fault. An app with a warm floor gets no such grace: it reports capacity_below_floor from the moment its workload is applied until its first worker is ready, so a normal first deploy reports it for the whole of its cold start. Use since to tell the two apart. A cold start clears within the app's startup time, and a real shortage does not. Neither names whose fault the shortfall is, and neither is a statement about charging. A worker the platform never placed holds no GPU and costs nothing, but the same two reasons also cover workers that were placed and cannot serve, and those hold a GPU. Some of those states are charged for and some are not: a container that crash-loops or one still loading is charged, while one still pulling its image is not. Read the app's workers to tell the cases apart. autoscaler_unhealthy means the autoscaler cannot act on the workload, so the app will not grow with demand. workload_present accompanies a healthy app. workload_terminating and workload_missing are a workload being removed or already gone, which a stop or a delete explains.

When the app entered this state. It moves only when state changes, so it answers how long the condition has held, the figure to quote when asking how long an app has been unable to serve.

When the platform last looked. It is rewritten on every observation, so it reports the freshness of the verdict and not the age of the condition. A value far in the past means nothing has observed the app recently.

Non-terminal workers (status other than stopped) on this app's active version. Pending workers count because they appear in the active-version workers list before Kubernetes assigns a GPU. Outgoing-version workers are excluded because the default workers list omits them. A deleted app reports zero.

Sum of gpuCount across those workers. A pending worker contributes zero until Kubernetes schedules it onto a node.

When this runtime snapshot was read from the database.

Requests served by this app in the last 24 hours. Omitted until available.

Error ratio (4xx + 5xx over requests) for this app in the last 24 hours, in 0–1. Omitted when metrics cannot be read or when the app had no requests in the window.

Mean inference request duration in seconds over the last 24 hours (all requests, the duration histogram has no status class). Omitted when metrics cannot be read, when the app had no requests, or when the duration series has no samples for the app in the window.

Ready plus unacknowledged messages on this app's live inference queue. Omitted when the app is not live or the gauge cannot be read. Zero when the queue is live and empty.

Organization-scoped secret name. The shape matches EnvironmentVariableName and the secrets.name / deployment_secrets.env_var_name column CHECKs, one rule for the contract and the schema, because attached secrets are intended to be injected as environment variables once ADR-019 in-pod unseal lands. Names the platform sets on the serving container (RUNTIME, DISABLE_NGINX, MLFLOW_MODELS_WORKERS, UVICORN_HOST) are rejected with 422: when injection exists, the deployer appends customer env after its own and kubelet resolves duplicates last-wins, so an accepted collision would silently replace a platform value. Same guard as plain environment variables. Enforced by the server (not expressible as a pattern here).

Kind of secret. Only the environment-variable variant (generic) is supported. Image-pull (registry) credentials are consumed by the kubelet before any container starts, so they cannot use the in-pod unseal path (ADR-019) and await their own decision.

Optional opaque metadata associated with the secret.

Resolved environment variable name when it differs from name. Omitted when the secret name is used. Same reserved-name rules as SecretName when set.

Immutable app identifier. Unique among the authenticated organization's live apps: it cannot be changed after creation, and it becomes available again once the app it named reaches deleted.

POSIX-style environment variable name. Letters, digits, and underscore. Must start with a letter or underscore. Matched by the deployment_configs column CHECK so a valid-by-contract request cannot 500 at INSERT.

Immutable app identifier. Unique among the authenticated organization's live apps: it cannot be changed after creation, and it becomes available again once the app it named reaches deleted.

Worker compute class. GPU is the only supported value. CPU workloads are not supported.

Preferred GPU type. Absent (or null) only on historical apps created before a GPU type was required.

Secondary GPU type recorded for this app. It is validated and stored, but placement does not yet substitute it: a worker that cannot get gpuType waits for that type rather than starting on this one. Do not rely on it as failover.

GPUs granted to one worker pod. Create and update accept only the group sizes the cluster grants indivisibly, since a worker holds its GPUs as one such group. Historical apps may contain another value.

Floor for scale-down. 0 = scale to zero.

Idle workers held above current demand, so a burst does not wait for a cold start. Null or 0 means no buffer. The buffer applies only while the queue is non-empty: an idle app still scales to minWorkers. A buffer below about a tenth of current demand is not added while demand holds steady. availableWorkersPct is not subject to that.

Idle workers held above current demand, as a percentage of that demand, rounded up. Null or 0 means no buffer. When both buffers are set the larger of the two applies. The buffer applies only while the queue is non-empty: an idle app still scales to minWorkers.

Seconds a worker can sit idle before the Scaler removes it.

Cooldown between consecutive scaling decisions.

How long the sidecar waits on one forwarded container request. Container-only: a code app keeps the platform MLflow read ceiling, so this field is stored and returned but is not applied to those reads. Bounds the worker, not the synchronous HTTP wait: invoke-sync still answers 504 at the platform deadline so the caller can poll. A later container.yaml deploy overwrites this with that document's timeouts.requestSeconds.

How long readiness has before the pod is failed. Rendered as the startup probe budget and the sidecar's own startup gate. A later container.yaml deploy overwrites this with that document's timeouts.startupSeconds.

Whether the app's workload can serve. healthy can serve. degraded can serve with less capacity than it asks for. unavailable has nothing able to serve. Read AppHealthReason for the cause. This is a report on the workload, not an admission rule. Only an active app is refused on it: an initializing app that already has a version to route to accepts invocations while it reports unavailable, which is the ordinary case during a first deploy, and a draining app is not gated on health at all. Do not read this field as whether the next invocation will be accepted.

Why the app holds its current health state. capacity_below_floor and demand_unserved are the two shapes of capacity exhaustion, and they differ in what the app asked for. capacity_below_floor means the app keeps a warm floor above zero and has fewer workers able to serve than that floor. demand_unserved means the app scales to zero, so it has no floor to be short of, and work is waiting on its queue with nothing running it. They behave differently during a cold start. An app waking from zero is given a grace period before it is called starved, so an ordinary wake-up is not reported as a fault. An app with a warm floor gets no such grace: it reports capacity_below_floor from the moment its workload is applied until its first worker is ready, so a normal first deploy reports it for the whole of its cold start. Use since to tell the two apart. A cold start clears within the app's startup time, and a real shortage does not. Neither names whose fault the shortfall is, and neither is a statement about charging. A worker the platform never placed holds no GPU and costs nothing, but the same two reasons also cover workers that were placed and cannot serve, and those hold a GPU. Some of those states are charged for and some are not: a container that crash-loops or one still loading is charged, while one still pulling its image is not. Read the app's workers to tell the cases apart. autoscaler_unhealthy means the autoscaler cannot act on the workload, so the app will not grow with demand. workload_present accompanies a healthy app. workload_terminating and workload_missing are a workload being removed or already gone, which a stop or a delete explains.

When the app entered this state. It moves only when state changes, so it answers how long the condition has held, the figure to quote when asking how long an app has been unable to serve.

When the platform last looked. It is rewritten on every observation, so it reports the freshness of the verdict and not the age of the condition. A value far in the past means nothing has observed the app recently.

Non-terminal workers (status other than stopped) on this app's active version. Pending workers count because they appear in the active-version workers list before Kubernetes assigns a GPU. Outgoing-version workers are excluded because the default workers list omits them. A deleted app reports zero.

Sum of gpuCount across those workers. A pending worker contributes zero until Kubernetes schedules it onto a node.

When this runtime snapshot was read from the database.

Requests served by this app in the last 24 hours. Omitted until available.

Error ratio (4xx + 5xx over requests) for this app in the last 24 hours, in 0–1. Omitted when metrics cannot be read or when the app had no requests in the window.

Mean inference request duration in seconds over the last 24 hours (all requests, the duration histogram has no status class). Omitted when metrics cannot be read, when the app had no requests, or when the duration series has no samples for the app in the window.

Ready plus unacknowledged messages on this app's live inference queue. Omitted when the app is not live or the gauge cannot be read. Zero when the queue is live and empty.

Organization-scoped secret name. The shape matches EnvironmentVariableName and the secrets.name / deployment_secrets.env_var_name column CHECKs, one rule for the contract and the schema, because attached secrets are intended to be injected as environment variables once ADR-019 in-pod unseal lands. Names the platform sets on the serving container (RUNTIME, DISABLE_NGINX, MLFLOW_MODELS_WORKERS, UVICORN_HOST) are rejected with 422: when injection exists, the deployer appends customer env after its own and kubelet resolves duplicates last-wins, so an accepted collision would silently replace a platform value. Same guard as plain environment variables. Enforced by the server (not expressible as a pattern here).

Kind of secret. Only the environment-variable variant (generic) is supported. Image-pull (registry) credentials are consumed by the kubelet before any container starts, so they cannot use the in-pod unseal path (ADR-019) and await their own decision.

Optional opaque metadata associated with the secret.

Resolved environment variable name when it differs from name. Omitted when the secret name is used. Same reserved-name rules as SecretName when set.

Immutable app identifier. Unique among the authenticated organization's live apps: it cannot be changed after creation, and it becomes available again once the app it named reaches deleted.

POSIX-style environment variable name. Letters, digits, and underscore. Must start with a letter or underscore. Matched by the deployment_configs column CHECK so a valid-by-contract request cannot 500 at INSERT.

Immutable app identifier. Unique among the authenticated organization's live apps: it cannot be changed after creation, and it becomes available again once the app it named reaches deleted.

Worker compute class. GPU is the only supported value. CPU workloads are not supported.

Preferred GPU type. Absent (or null) only on historical apps created before a GPU type was required.

Secondary GPU type recorded for this app. It is validated and stored, but placement does not yet substitute it: a worker that cannot get gpuType waits for that type rather than starting on this one. Do not rely on it as failover.

GPUs granted to one worker pod. Create and update accept only the group sizes the cluster grants indivisibly, since a worker holds its GPUs as one such group. Historical apps may contain another value.

Floor for scale-down. 0 = scale to zero.

Idle workers held above current demand, so a burst does not wait for a cold start. Null or 0 means no buffer. The buffer applies only while the queue is non-empty: an idle app still scales to minWorkers. A buffer below about a tenth of current demand is not added while demand holds steady. availableWorkersPct is not subject to that.

Idle workers held above current demand, as a percentage of that demand, rounded up. Null or 0 means no buffer. When both buffers are set the larger of the two applies. The buffer applies only while the queue is non-empty: an idle app still scales to minWorkers.

Seconds a worker can sit idle before the Scaler removes it.

Cooldown between consecutive scaling decisions.

How long the sidecar waits on one forwarded container request. Container-only: a code app keeps the platform MLflow read ceiling, so this field is stored and returned but is not applied to those reads. Bounds the worker, not the synchronous HTTP wait: invoke-sync still answers 504 at the platform deadline so the caller can poll. A later container.yaml deploy overwrites this with that document's timeouts.requestSeconds.

How long readiness has before the pod is failed. Rendered as the startup probe budget and the sidecar's own startup gate. A later container.yaml deploy overwrites this with that document's timeouts.startupSeconds.

Whether the app's workload can serve. healthy can serve. degraded can serve with less capacity than it asks for. unavailable has nothing able to serve. Read AppHealthReason for the cause. This is a report on the workload, not an admission rule. Only an active app is refused on it: an initializing app that already has a version to route to accepts invocations while it reports unavailable, which is the ordinary case during a first deploy, and a draining app is not gated on health at all. Do not read this field as whether the next invocation will be accepted.

Why the app holds its current health state. capacity_below_floor and demand_unserved are the two shapes of capacity exhaustion, and they differ in what the app asked for. capacity_below_floor means the app keeps a warm floor above zero and has fewer workers able to serve than that floor. demand_unserved means the app scales to zero, so it has no floor to be short of, and work is waiting on its queue with nothing running it. They behave differently during a cold start. An app waking from zero is given a grace period before it is called starved, so an ordinary wake-up is not reported as a fault. An app with a warm floor gets no such grace: it reports capacity_below_floor from the moment its workload is applied until its first worker is ready, so a normal first deploy reports it for the whole of its cold start. Use since to tell the two apart. A cold start clears within the app's startup time, and a real shortage does not. Neither names whose fault the shortfall is, and neither is a statement about charging. A worker the platform never placed holds no GPU and costs nothing, but the same two reasons also cover workers that were placed and cannot serve, and those hold a GPU. Some of those states are charged for and some are not: a container that crash-loops or one still loading is charged, while one still pulling its image is not. Read the app's workers to tell the cases apart. autoscaler_unhealthy means the autoscaler cannot act on the workload, so the app will not grow with demand. workload_present accompanies a healthy app. workload_terminating and workload_missing are a workload being removed or already gone, which a stop or a delete explains.

When the app entered this state. It moves only when state changes, so it answers how long the condition has held, the figure to quote when asking how long an app has been unable to serve.

When the platform last looked. It is rewritten on every observation, so it reports the freshness of the verdict and not the age of the condition. A value far in the past means nothing has observed the app recently.

Non-terminal workers (status other than stopped) on this app's active version. Pending workers count because they appear in the active-version workers list before Kubernetes assigns a GPU. Outgoing-version workers are excluded because the default workers list omits them. A deleted app reports zero.

Sum of gpuCount across those workers. A pending worker contributes zero until Kubernetes schedules it onto a node.

When this runtime snapshot was read from the database.

Requests served by this app in the last 24 hours. Omitted until available.

Error ratio (4xx + 5xx over requests) for this app in the last 24 hours, in 0–1. Omitted when metrics cannot be read or when the app had no requests in the window.

Mean inference request duration in seconds over the last 24 hours (all requests, the duration histogram has no status class). Omitted when metrics cannot be read, when the app had no requests, or when the duration series has no samples for the app in the window.

Ready plus unacknowledged messages on this app's live inference queue. Omitted when the app is not live or the gauge cannot be read. Zero when the queue is live and empty.

Organization-scoped secret name. The shape matches EnvironmentVariableName and the secrets.name / deployment_secrets.env_var_name column CHECKs, one rule for the contract and the schema, because attached secrets are intended to be injected as environment variables once ADR-019 in-pod unseal lands. Names the platform sets on the serving container (RUNTIME, DISABLE_NGINX, MLFLOW_MODELS_WORKERS, UVICORN_HOST) are rejected with 422: when injection exists, the deployer appends customer env after its own and kubelet resolves duplicates last-wins, so an accepted collision would silently replace a platform value. Same guard as plain environment variables. Enforced by the server (not expressible as a pattern here).

Kind of secret. Only the environment-variable variant (generic) is supported. Image-pull (registry) credentials are consumed by the kubelet before any container starts, so they cannot use the in-pod unseal path (ADR-019) and await their own decision.

Optional opaque metadata associated with the secret.

Resolved environment variable name when it differs from name. Omitted when the secret name is used. Same reserved-name rules as SecretName when set.

Immutable app identifier. Unique among the authenticated organization's live apps: it cannot be changed after creation, and it becomes available again once the app it named reaches deleted.

POSIX-style environment variable name. Letters, digits, and underscore. Must start with a letter or underscore. Matched by the deployment_configs column CHECK so a valid-by-contract request cannot 500 at INSERT.

Immutable app identifier. Unique among the authenticated organization's live apps: it cannot be changed after creation, and it becomes available again once the app it named reaches deleted.

Worker compute class. GPU is the only supported value. CPU workloads are not supported.

Preferred GPU type. Absent (or null) only on historical apps created before a GPU type was required.

Secondary GPU type recorded for this app. It is validated and stored, but placement does not yet substitute it: a worker that cannot get gpuType waits for that type rather than starting on this one. Do not rely on it as failover.

GPUs granted to one worker pod. Create and update accept only the group sizes the cluster grants indivisibly, since a worker holds its GPUs as one such group. Historical apps may contain another value.