Names and limits
Naming rules for apps, slots and hostnames, and the limits on environment variables, scaling, retention and history.
App names
- Lowercase letters, digits and hyphens, starting with a letter and ending with a letter or digit.
- 3 to 50 characters in the portal; the API accepts up to 63.
- Unique in the resource group, and cannot be changed.
Slot names
- Lowercase letters, digits and hyphens, starting and ending with a letter or digit.
- Up to 12 characters (2 to 12 in the portal), and unique within the app.
- Not
default. The portal refuses it; the API accepts it, but a slot nameddefaultis dropped the next time the app is saved. - Part of the slot's hostname; cannot be changed.
Hostnames
- A domain you give an app is a fully qualified domain name in lowercase: no scheme, port, path, wildcard or trailing dot, and at most 253 characters.
- A generated hostname has the form
<prefix>-<resource group>-<app>.apps.example.com— see The generated hostname. - A hostname belongs to one resource in the cluster at a time, across all boundaries; the platform refuses one that is already in use — see Hostnames already in use.
Ports
The app's port is 1 to 65535. An environment variable named PORT must have the same value.
Environment variables
| Limit | Value |
|---|---|
| Name | A letter or underscore, then letters, digits and underscores |
| Name in the portal's create wizard | 2 to 100 characters |
| Value in the portal's create wizard | At most 500 characters |
| Value | At most 32 KiB |
| All names and values together | At most 256 KiB |
| Build variables | At most 32, each one of the app's settings, never a secret reference |
Scaling
| Setting | Range |
|---|---|
| Manual instances | 1 to 20; the API also takes 0, which stops the app |
| Horizontal Pod Autoscaler | Minimum at least 1, maximum at most 20, CPU threshold 1 to 100 % |
| KEDA | Minimum 0 or more, maximum 1 to 20, at least one trigger; pollingInterval at least 1 second, cooldownPeriod 0 or more |
An app that ran above 20 instances before the limit existed keeps its count, but cannot go higher. A slot runs one instance.
KEDA triggers
The platform accepts these trigger types: aws-sqs-queue, azure-queue, azure-servicebus,
cpu, cron, gcp-pubsub, kafka, memory, metrics-api, mongodb, mssql, mysql,
nats-jetstream, postgresql, prometheus, rabbitmq, redis, redis-streams. The metadata
the portal's types require is listed on Scaling.
Image retention
Important
Today the registry's clean-up removes no app images: every image built for an app is kept, and the policy below, including an app's own
retention, has no effect.
The platform's registry has a retention policy for the images built for each app: keep the images
that run and — by default — the last two images built and every image built in the last 90 days;
your platform administrator can change those defaults. A daily clean-up is to remove the rest. An
app can set its own numbers with a retention object in the request that creates it:
{
"retention": { "keepLast": 5, "keepForDays": 30 }
}keepLast— keep at least this many of the most recent images.keepForDays— keep every image built within this many days.
Leave either out to use the platform's default for it. With the CLI, put the object in the file you
pass to stsh apps create --file. The portal has no field for it, and changing retention on an
existing app through the API has no effect today.
Other limits
| What | Limit |
|---|---|
| Build logs | Kept for 30 days |
| Revisions | The last 50 are kept |
| One file upload | 512 MiB, unless your platform administrator set another limit |