Skip to main content
Runtime settings control how big your container is, how it starts and stops, and where it runs. Each of an has its own.

​
Change runtime settings

Edit them under App settings in the dashboard, with environments.updateSettings in the API, or with unkey api environments update-settings in the CLI. In the API, send only the fields you want to change. environments.getEnvironment returns the current values under runtime and regions. In the dashboard, the settings are in two places:
  • Environments opens a page for each environment. Click Configure on its Runtime card to set regions, size (CPU and memory), instances, storage, port, start command, health check path, and health check interval.
  • Advanced holds the OpenAPI spec path and upstream protocol.
Everything on the Runtime card is saved for that one environment only. Advanced shows the production values, and saving there writes to every environment of the app. To give production and preview a different protocol, use the API or CLI. A change applies from the next deployment, and the dashboard shows “Changes apply to the next deployment” on a group with unsaved edits. Running deployments keep what they started with, so to apply a change without new code, redeploy the current deployment. Your plan caps CPU, memory, and disk per instance. Going over returns 400 with a message like “CPU per instance cannot exceed 2 vCPU. Contact support@unkey.com to increase it.” See Compute limits.

​
Container

​
integer
default:"8080"
The port your container listens on, 1 to 65535. We set it as the PORT environment variable, overriding any value in the image, and send traffic and health checks to it. A port outside the range fails the deployment with invalid_runtime_settings.
​
number
default:"0.25"
CPU per instance in vCPUs, at least 0.25, in steps of 0.25, up to your plan’s limit. An instance can use up to this much and is always guaranteed at least half. In the dashboard, set it with Size on the environment’s Runtime card. The presets are XS (1/4 vCPU, 256 MiB), S (1/2 vCPU, 1 GiB), M (1 vCPU, 2 GiB), L (2 vCPU, 4 GiB), XL (4 vCPU, 8 GiB), 2XL (8 vCPU, 16 GiB), and 4XL (16 vCPU, 32 GiB). A preset above your plan shows a lock and the plan that unlocks it. Custom sets CPU and memory on their own, in the same steps, up to what your plan allows.
​
integer
default:"256"
Memory per instance in MiB, at least 256, in steps of 256, up to your plan’s limit. It’s a hard limit: an instance that goes over is killed and restarted, and the dashboard shows OOMKilled with exit code 137. In the dashboard, it’s part of Size on the environment’s Runtime card.
​
integer
default:"0"
Temporary disk per instance in MiB, in steps of 512, up to your plan’s limit. 0 means none. When set, each instance gets its own disk at /data, and UNKEY_EPHEMERAL_DISK_PATH is set to /data. Nothing on it survives a restart or a new deployment. Without it, the container can write at most 128 MiB. The dashboard’s Storage field offers None, 512 MiB, and 1, 2, 5, 10, 20, and 50 GiB, up to what your plan allows. A value set through the API that isn’t a preset shows as an extra option.
​
string[]
default:"[]"
Replaces the image’s command, as an array of up to 10 strings of up to 4096 characters each. An empty array runs the image’s own command. The dashboard splits a single line on spaces and ignores quotes, so use the API when an argument contains spaces.
​
SIGTERM | SIGINT | SIGQUIT | SIGKILL
default:"SIGTERM"
The signal your container’s main process gets when an instance is replaced or scaled in. Set it with the API or CLI. It isn’t in the dashboard.
​
http1 | h2c
default:"http1"
How the gateway talks to your container. http1 is HTTP/1.1 and works with every framework. h2c is HTTP/2 without TLS. Choose it only if your server supports h2c.
​
string | null
The path where your app serves its OpenAPI document, for example /openapi.yaml. 1 to 512 characters, starting with / and matching ^(/[\w\-]+)+(\.[\w]+)?$. When a deployment is ready, we fetch the document with a GET and save it with that deployment. Documents up to 10 MiB are accepted, and a 404 means the deployment has no spec. The spec is used by the gateway’s OpenAPI validation policy and the dashboard’s spec diff. Send null, or leave the dashboard field empty, to turn this off.
​
object | null
An HTTP check we run against each instance. See Health checks. Send null to remove it.

​
Regions and replicas

​
EnvironmentRegion[]
The regions the environment runs in, 1 to 5 entries, each like { "name": "us-east-1", "replicas": { "min": 1, "max": 3 } }. The list replaces the whole set, so regions you leave out are removed. In the dashboard, the Regions and Instances fields on the environment’s Runtime card edit this field. When you change Instances or add a region, the dashboard writes the same min and max to every region.
  • The region must be available, or you get “Region ‘x’ is not available for scheduling.”
  • Each region can appear once.
  • min is at least 1. max is at least min and at most your plan’s replicas-per-region limit.
  • Every region must use the same bounds, or you get “All regions must specify the same replica bounds; per-region autoscaling is not supported yet.”
A new app created with the API starts in one schedulable region, with min and max both 1, so autoscaling is off until you raise max. In the dashboard, a new app starts in every region available to the workspace. Pick your regions before you go live. See Regions.

​
Raise resources and add a region

Raise resources and add a second region
The Regions field on the environment’s Runtime card lists the regions you can use. The change applies from the next deployment.

​
Next steps

Health checks

Probe fields, defaults, and what a failing probe does.

Instances and autoscaling

What the allocation and replica bounds mean at runtime.

Compute limits

The per-instance and workspace ceilings behind the 400s.

Regions

How regions are discovered, chosen, and used for failover.
Last modified on October 22, 2026