v0.10.2 adds support for Ruby 3.
v0.10.0 brings several fixes and a few new features:
Check out the gem’s change log for more details.
I’ve removed the old Heroku nav bar (they no longer require it for add-ons) and updated the Rails Autoscale nav bar to include app info and wrap more nicely with lots of worker processes. You can also now adjust the vertical scale of your queue time chart, making it much easier to see differences in lower queue time values.
The old plans (Bronze, Silver, Gold, Platinum) have been replaced by plans specific to dyno types—Bronze-Standard, Bronze-Performance, Silver-Standard, etc. The official listing of available plans is on the Heroku Elements page, and more details are on Rails Autoscale’s Plans & Pricing docs page.
The Rails Autoscale API can now be used to update your app settings. Some customers are using this endpoint to have different autoscale settings on a schedule, such as more lenient settings on the weekend.
Previously, updating your “autoscale limit” settings would have no immediate effect. The limit was only changed when an upscale or downscale threshold was breached.
Now, Rails Autoscale will immediately check to see if your app is running within your new autoscale limit. If your app is scaled outside that range, you’ll autoscale up or down as necessary to satisfy the limit.
v0.9.0 brings major improvements for worker backends and logging:
The page you’re reading right now. 😁 I haven’t been great about tracking and sharing product updates, and this is my attempt to do better.
The official docs site is live! Prior to this, the only documentation was in the Heroku Dev Center, and it was insufficient. The new docs site will be the official canonical docs, frequently updated, and as extensive as possible.
A few bugfix releases were needed to address edge cases with Delayed Job and Que reporting.
Autoscaling Resque has been the top feature request ever since Sidekiq autoscaling was launched in 2019. Currently beta testing with several customers.
Request queue times can be skewed when Puma spends time waiting for large request bodies to be transferred by slow clients. That time does not indicate a capacity issue, and thus should not be factored into request queue time for autoscaling purposes.
Heroku does not allow free and hobby dynos to be scaled to more than one dyno, so Rails Autoscale had previously shown an error message if you attempted to enable autoscaling on these dynos. Some customers are autoscaling worker dynos down to zero dynos, though, and there’s no reason you shouldn’t be able to autoscale free/hobby dynos from 0-to-1. You can do that now.
Your Rails Autoscale dashboard now links to a “Dyno Usage” page. This page shows a daily breakdown of how many dyno-hours you’ve used, the cost of those dynos, and the money saved by autoscaling. Here’s one crazy example.
Delayed Job and Que have joined Sidekiq in the job backends supported by worker autoscaling. 🚀