Since launching Rails Autoscale in the Heroku add-on marketplace in 2017, I’ve had customers wanting more control. I’d been resistant for over two years because I was determined to build an autoscaler that doesn’t need those controls. One reason I created Rails Autoscale was the overwhelming nature of existing solutions—too many knobs and switches!
My approach was to minimize the amount of configuration available and to provide sensible defaults for the necessary remaining options.
For some customers, though, this is insufficient. As Rails Autoscale has gotten more popular, and especially after the launch of worker autoscaling, the voices calling for more control and configuration have only gotten more persistent.
I’ve been listening all along, and last month I quietly launched a new feature that I hope finds a solid middle ground, providing a way to tweak autoscaling behavior in very precise ways while remaining easy to use and staying out of the way if you don’t need it.
The advanced options are hidden by default. I still believe most apps should leave the defaults untouched, but for those who need that extra bit of control, now you’ve got it.
How do you know if you need the advanced options? Here’s an example.
Say it’s common for your app to experience sudden spikes of traffic, orders of magnitude higher than normal. The default autoscaling behavior of scaling up one dyno at a time everything three minutes might not be able to keep up with this traffic pattern. In this case, you may find that scaling up by two dynos (or more) at a time is a better fit.
Using the advanced options, you can now scale up by many dynos at a time. Or shorten the time between upscales. Whatever you need. Overkill for most apps, but necessary for some.
I hope you enjoy these new configuration options, and as always, I’d love to hear what you think.