Last updated December 03, 2024

This article has instructions for manually scaling your app by changing the dyno size or number of dynos in your formation. Autoscaling is also available for some dyno tiers.

Change the Number of Dynos

Scaling a process type horizontally provides additional concurrency for performing the work handled by that process type. For example, adding more web dynos allows you to handle more concurrent HTTP requests. Adding more worker dynos lets you process more jobs in parallel.

See Dyno Scaling and Process Limits for the maximum number of dynos you can run per dyno type.

With the Heroku Dashboard

1. From the Heroku Dashboard, select your app.
2. Go to the Resources tab.
3. Click the edit icon beside a process type, for example web.
4. Move the slider or manually type in the number of desired dynos.
5. Click Confirm.

With the Heroku CLI

You can change the number of dynos with heroku ps:scale. For example, heroku ps:scale web=3.

You can also change the number of dynos for multiple processes at the same time. For example, heroku ps:scale web=1 worker=5

You can also change both the dyno size and the number of dynos for a process at the same time with heroku ps:scale. For example, heroku ps:scale web=3:performance-l.

With the Heroku API

See the Formation endpoints in the Heroku Platform API to change the dyno size or number of dynos in your dyno formation.

Autoscaling

Heroku offers Autoscaling for Performance-, Private- and Shield-tier dynos. If that feature doesn’t meet your needs, consider a third-party add-on from the Elements marketplace.

Change the Dyno Size

Scale vertically by changing its size to change the resources available to each dyno. For guidance on selecting the correct size, see Guidance for Choosing a Dyno.

With the Heroku Dashboard

Common Runtime Apps

1. From the Heroku Dashboard, select your app.
2. Go to the Resources tab.
3. Above your list of dynos, click Change Dyno Type.
4. Click the desired dyno tier.
5. Click Save.
6. Click the icon beside your listed processes to open the dyno size dropdown menu.
7. Select a size. Eco and Basic tiers only have one size.

Private Space Apps

1. From the Heroku Dashboard, select your app.
2. Go to the Resources tab.
3. Click the icon beside your listed processes to open the dyno size dropdown menu.
4. Select a size.

With the Heroku CLI

You can change the dyno size for a process by using heroku ps:type. For example, heroku ps:type worker=standard-2x.

You can also change both the dyno size and the number of dynos for a process at the same time with heroku ps:scale. For example, heroku ps:scale web=3:performance-l.

With the Heroku API

See the Formation endpoints in the Heroku Platform API to change the dyno size or number of dynos in your dyno formation. To find an list of available dyno types for your app, query the Dyno Size endpoint.

Considerations

Scaling Limits

See Dyno Scaling and Process Limits for the maximum number of dynos you can run per dyno size.

Mixing Dynos Tiers

Apps on the eco or basic tiers don’t allow for mixing of various dyno types. Apps in these tiers must only use the same type of dyno for all processes.

For rest of our dyno offerings, we offer the ability to mix any dynos that are scoped to that specific runtime tier. We don’t allow the mixing of dynos across various runtimes.

Some examples of this:

• An app in our Common Runtime could have a performance-m web process and a standard-1x worker.
• An app in a Private Space could have a private-l web process and a private-m worker process.
• An app in a Shield Space could have a shield-l web process and a shield-m worker process.
• An app in a Fir Space could have a 1x-classic web process and a 2x-compute worker process.

When Not to Add Dynos

Singleton Processes

Never scale singleton process types, such as a clock/scheduler process type beyond a single dyno. These process types don’t benefit from additional concurrency and can create duplicate records or events.

Backing Service Bottlenecks

Sometimes a bottleneck limits your app’s performance. This bottleneck can come from a backing service, most commonly the database. Adding more dynos in this case can make the problem worse. Fix your bottleneck issues first. For example, if it’s a database, you can try to:

• Optimize your database queries
• Upgrade to a larger database
• Implement caching to reduce database load
• Switch to a sharded configuration, or scale reads using followers

Long-Running Jobs

Adding more dynos can’t help with large, monolithic HTTP requests, such as a report with a database query that takes 30 seconds, or a job to email out your newsletter to 20,000 subscribers. Try dividing the work first so that adding more dynos makes sense as they run jobs in parallel. See Worker Dynos, Background Jobs and Queueing for more info.

Threads and Requests

A single dyno can serve thousands of requests per second, but performance depends greatly on the language and framework you use. A single-threaded, non-concurrent web framework, like Rails 3 in its default configuration, can process one request at a time. For an app that takes 100ms on average to process each request, it translates to about 10 requests per second per dyno, which isn’t optimal.

Additional Reading

• Dyno Scaling and Process Limits
• Autoscaling Dynos
• Dyno Tiers
• Dyno Formation
• Application Load Testing
• Dyno CLI and API Commands