Skip to main content
Handle varying workloads by running multiple replicas of your Servers. For installations that receive traffic, Ryvn automatically distributes it evenly across your running replicas.
Installations with persistent storage cannot scale to multiple replicas.

​
Scaling methods

Ryvn supports two primary methods for scaling your applications:

Manual scaling

Run a fixed number of replicas that you specify.

Autoscaling

Automatically adjusts replica count based on one or more triggers: CPU/memory utilization, Temporal task queue depth, RabbitMQ queue metrics, Prometheus queries, or a weekly schedule.

​
Manual scaling

Manual scaling gives you direct control over your application’s capacity by running a fixed number of replicas. Each replica runs an identical copy of your application, and Ryvn’s load balancer automatically distributes incoming requests across all available replicas. To configure manual scaling:
1

Navigate to Environments

Go to the Environments tab in the Ryvn Dashboard
2

Select environment

Choose the environment containing your installation
3

Select installation

Click on the installation you want to configure
4

Configure scaling

  1. In the Scaling section, select Manual Scaling
  2. Enter the desired number of replicas (up to 100)
  3. Click Save to apply the changes
When you update the number of replicas, Ryvn immediately begins provisioning or deprovisioning replicas to match your desired count. You can scale your installation up to a maximum of 100 replicas.

​
Autoscaling

Autoscaling provides dynamic resource management by automatically adjusting the number of running replicas based on real-time metrics. You can combine multiple triggers so that Ryvn scales on whichever metric demands the most replicas.

​
Configuration

To configure autoscaling:
1

Navigate to Environments

Go to the Environments tab in the Ryvn Dashboard
2

Select environment

Choose the environment containing your installation
3

Select installation

Click on the installation you want to configure
4

Enable autoscaling

  1. In the Scaling section, select Autoscaling
  2. Set the minimum and maximum number of replicas
  3. Click Add Trigger to add one or more autoscaling triggers
  4. Click Save to apply the changes
  • minReplicas: Ryvn will maintain at least this many replicas, even during low utilization. Set to 0 to allow scaling to zero when all triggers are idle.
  • maxReplicas: Ryvn will not exceed this number of replicas, even during high utilization
  • triggers: One or more scaling triggers that determine when to scale (see below)

​
Trigger types

You can add any combination of the following triggers. When multiple triggers are active, Ryvn scales based on whichever trigger requires the most replicas.

​
CPU / memory

Scale based on average CPU and/or memory utilization across all running replicas.
  • CPU target: The CPU utilization percentage that triggers scaling (recommended: 70-80%)
  • Memory target: The memory utilization percentage that triggers scaling (recommended: 80-85%)
You can enable both metrics or just one. Ryvn uses the formula new_replicas = ceil(current_replicas * (current_util / target_util)) to calculate the desired replica count.

​
Temporal queue

Scale based on the depth of a Temporal task queue. This is useful for worker installations that process tasks from a Temporal workflow.
  • Connection Mode: Either Saved Integration (use a configured Temporal integration for your organization) or Manual Endpoint (connect directly to a Temporal server with no Ryvn-managed API key)
  • Integration: In Saved Integration mode, select a configured Temporal integration for your organization
  • Task Queue: The name of the Temporal task queue to monitor
  • Target Queue Size: The number of pending tasks per replica that triggers scaling
  • Worker Deployment: Optional (IaC only). When your workers use Temporal Worker Versioning, set workerDeployment.name so the scaler measures that Worker Deployment’s backlog. The worker build ID is injected as RYVN_RELEASE_VERSION and is not configurable.
In Saved Integration mode you can optionally override the endpoint and namespace from the selected integration. In Manual Endpoint mode, the endpoint and namespace are required.

​
RabbitMQ queue

Scale based on RabbitMQ queue metrics. This is useful for consumer installations that process messages from a RabbitMQ queue.
  • Connection Method: Either provide a direct endpoint URL or reference an environment variable (defaults to RABBITMQ_HOST)
  • Queue Name: The RabbitMQ queue to monitor
  • Scaling Mode: Scale by Queue Length (pending messages per replica) or Message Rate (messages per second per replica)
  • Protocol: AMQP or HTTP (the HTTP management API). Message Rate mode requires HTTP
  • Target Value: The threshold per replica that triggers scaling

​
Prometheus query

Scale on the numeric result of a query against a Prometheus-compatible endpoint. The endpoint must be reachable from the installation’s environment and accept unauthenticated requests.
  • Server Address: An absolute http:// or https:// URL for the endpoint
  • Query: A Prometheus-compatible query that returns one numeric value
  • Threshold: A positive number that determines when KEDA scales the installation
  • Activation Threshold: An optional non-negative value that the metric must cross before scaling from zero. Defaults to 0
  • Metric Type: AverageValue treats the threshold as a per-replica target. Value treats it as a target for the entire installation. Defaults to AverageValue
Prometheus triggers currently connect without authentication. If the query fails three times in a row, Ryvn uses a fallback of max(1, minReplicas) until the endpoint responds again.

​
Weekly schedule

Scale to a fixed replica count during a recurring time window. This is useful for predictable load patterns — business hours, batch windows, or scheduled scale-to-zero for non-production environments.
  • Days: One or more lowercase weekday names (monday through sunday). Each selected day gets its own window using the same start and end times
  • Start Time: The beginning of the window on each selected day, in 24-hour HH:MM format
  • End Time: The end of the window on each selected day, in 24-hour HH:MM format. It must be after startTime on the same day
  • Timezone: An IANA Time Zone Database name (e.g., America/New_York) the times are evaluated in
  • Desired Replicas: The replica count to maintain while inside the window. Must not exceed maxReplicas
A few things to keep in mind:
  • The desired count is a floor, not a cap. When combined with other triggers, whichever trigger demands the most replicas wins — a schedule trigger cannot scale your installation below what a CPU or queue trigger is requesting.
  • Outside the window, replicas fall to whatever other triggers demand, or to minReplicas when no trigger is active. With minReplicas: 0 and no other active triggers, the installation scales to zero.
  • Scale-out begins at the window start — pods still need to start and become ready. If you need full capacity at 9:00, open the window at 8:50.
  • Scale-down lags the window end by a short cool-down period (about five minutes).
You can add multiple schedule triggers for different windows (for example, 5 replicas on weekdays and 2 on weekends); where windows overlap, the highest desired count wins.

​
How autoscaling works

Ryvn continuously monitors the metrics defined by your triggers. When any trigger exceeds its target, the following process occurs:
1

Evaluate triggers

Ryvn evaluates each active trigger and calculates the replica count each one requires.
2

Determine scaling need

The highest replica count across all triggers is used as the desired count.
3

Scale up

If more replicas are needed, Ryvn immediately provisions new replicas to handle the increased load.
4

Scale down

If fewer replicas are needed, Ryvn waits for a cool-down period before removing replicas to prevent rapid fluctuations.

​
Best practices

When implementing scaling for your applications, consider the following recommendations:
Start with manual scaling to understand your application’s baseline resource needs and traffic patterns. This information will help you set appropriate autoscaling parameters later.
Set your CPU target between 70-80% and memory target between 80-85%. These ranges provide good resource utilization while maintaining headroom for traffic spikes.
For Temporal or RabbitMQ triggers, start with a conservative target value and adjust based on your workers’ throughput. Combine a queue trigger with a CPU/Memory trigger to handle both queue backlogs and resource-intensive workloads.
For production servers, configure a minimum of two replicas to maintain high availability. Consider your application’s cold start time when setting the minimum replica count.
Regularly review your scaling patterns and adjust thresholds based on actual usage and application performance metrics.

​
Monitoring and debugging

You can monitor your server’s scaling behavior through the Ryvn Dashboard, which provides real-time visibility into:
  • Current replica count and status
  • Scaling events history
  • CPU and memory utilization metrics
  • Queue depth and message rate for queue-based triggers
For advanced scaling scenarios or help with debugging scaling issues, please reach out to our support team.