Scaling

Open the app, then Configuration → Scaling, choose the Scaling Type and save. Scaling adds or removes instances; it does not rebuild the app or replace the instances that run.

A fixed number of instances

None (manual) runs the number of instances in Replicas, 1 to 20.

Scale on CPU use

Metrics based scale out (horizontally) uses a Kubernetes Horizontal Pod Autoscaler:

• Min Replicas — at least 1.
• Max Replicas — at most 20, and not below the minimum.
• CPU Threshold for scale-out — 1 to 100 %. Instances are added when their average CPU use, measured against the CPU of the app's compute plan, is above it, and removed when it falls.

Scale on events

Event driven autoscaling (horizontally) uses KEDA:

• Min Replicas — 0 or more. With 0 the app scales to zero when no trigger is active, and has no instance to answer requests until a trigger starts one. While it is at zero its status is Stopped.
• Max Replicas — 1 to 20, and not below the minimum.
• Triggers — at least one. KEDA scales when any of them fires. Choose a Trigger Type and fill in its Metadata, the key-value settings of that KEDA scaler.

The list offers RabbitMQ, Kafka, Azure Service Bus, Prometheus, Cron (time-based), Redis and PostgreSQL; Custom… takes any other type the platform accepts — see KEDA triggers. For the offered types the platform requires these metadata keys:

Type	Required metadata
cron	timezone, start, end, desiredReplicas
rabbitmq	queueName, and host or hostFromEnv
kafka	bootstrapServers or bootstrapServersFromEnv, and consumerGroup or consumerGroupFromEnv
azure-servicebus	queueName or topicName (with subscriptionName), and connectionFromEnv
prometheus	serverAddress, query, threshold
redis	listName, and one of address, addresses, addressFromEnv, host, hosts, hostFromEnv
postgresql	query, targetQueryValue, and connectionFromEnv or host

Any other type needs at least one metadata value. A trigger has no separate credentials: give connection details in the metadata, directly or — with a key ending in FromEnv — as the name of one of the app's environment variables.

Caution

A trigger's metadata, like the app's environment variables, is stored in plain text, and everyone with apps/read on the app can read it. The app's secrets are not environment variables, so a trigger cannot use one. When a scaler needs credentials, give it its own with no more access than scaling needs — for example read-only access to the queue — rather than the credentials the app uses.

Through the API, scaling.keda.pollingInterval (seconds between checks, at least 1) and scaling.keda.cooldownPeriod (seconds after the last active trigger before scaling back down, 0 or more) can be set too; without them KEDA's defaults apply.

When autoscaling does not work

The platform accepts an autoscaling configuration even when the cluster cannot act on it, for example when it has no metrics service or no KEDA. The app then stays at its current number of instances, and the Overview shows Auto Scaling as Not working with the reason under Scaling issue.

Good to know

• An app set above 20 instances before that limit existed keeps its count, but cannot go higher.
• Stopping an app remembers its scaling, and starting it brings it back — see Start, stop and restart. A scaling change saved while the app is stopped takes effect when it starts.
• A slot runs one instance; slots have no scaling settings.