Skip to content

Application Scalability

Before you scale an app, make sure the underlying Kubernetes cluster can scale with it.

Managed Kubernetes clusters give you the most flexibility because they can scale worker nodes dynamically through a cluster autoscaler. With K3S, app scaling is limited by the number of servers you connect to the cluster.

Manual scaling

You can scale the replica count of app services manually when the selected service revision supports horizontal scaling. The service overview shows whether horizontal scaling is supported.

Stateless services can usually be scaled up and down directly. Stateful services need service-specific support for scaling, for example through read replicas. A fixed service can be scaled to zero or run as a single replica, but it cannot be configured with multiple replicas.

You can set replica counts:

  • in the stack configuration as the default
  • per app instance as an override

Resources management

App services can define resource requests and limits, following the same model as Kubernetes container resources.

Resource limits help contain bursty workloads so they do not affect other workloads on the same cluster. Resource requests help Kubernetes schedule pods correctly and also matter for both pod autoscaling and cluster autoscaling.

CPU requests and limits are specified in millicores, where 1000 millicores equals 1 CPU core. Memory requests and limits are specified in mebibytes, where 1024 MiB is roughly 1 GiB.

You can define resources at:

  • stack level
  • app-service level

Autoscaling rules

Autoscaling requires an active paid subscription. Manual replica scaling remains available on all active plans. If your current subscription does not include autoscaling, you cannot enable or increase a rule, but you can turn an existing rule off.

When creating an app, you can define autoscaling rules for supported services. You can change the rule later from Apps > your app > your instance > Stack > App services > your service > Configuration > General.

Turn Autoscaling on to reveal:

  • Requested CPU for the primary container, in millicores
  • Minimum replicas
  • Maximum replicas
  • Avg. CPU utilization, as a percentage of requested CPU

Requested CPU must be at least 100 millicores. If the primary container already has a CPU request, the field is pre-filled with that value. Changing it here updates the same app-service resource override shown on the Resources tab before Wodby enables the autoscaling rule.

While autoscaling is on, the manual Replicas field is disabled. Wodby controls the replica count between the configured minimum and maximum, using the minimum as the baseline. Turn Autoscaling off to clear the saved rule and manage Replicas manually again.

The dashboard offers new autoscaling configuration only for eligible top-level, non-external services whose service revision supports horizontal scaling. If an existing rule becomes ineligible, its configuration remains visible so you can turn it off, but its settings cannot be increased. The API rejects enabling autoscaling for other services.

The current autoscaling signal is average CPU utilization. The target is expressed as a percentage of the configured CPU request. For example, if a service has a CPU request of 2000 millicores and an autoscaling target of 50%, scaling starts when average CPU usage reaches 1000 millicores.

The replica range works as follows:

  • the minimum replica count is the baseline when CPU usage stays below the target
  • the maximum replica count is the upper limit autoscaling can grow to

The autoscaling controls remain available when the app service is disabled. Disabling an app service preserves its autoscaling rule for a future re-enable; it does not turn autoscaling off or remove the service as a subscription downgrade blocker. To remove the rule, open the disabled service's Configuration > General page, turn Autoscaling off, and select Update.

Vertical scaling

Coming soon...