Our customers on AWS now have the option of using Terraform (instead of CloudFormation) to setup Judoscale's connection to their ECS clusters. You'll see this option when creating a new team or enabling autoscaling for the first time.
👉 For more info including a video walkthrough, check out our docs.
You can now use Judoscale with any cloud provider that exposes an API for scaling, if you're willing do a bit of integration work yourself. You just provide a thin wrapper around that API that acts as the glue between the provider and Judoscale, and Judoscale handles the rest.
We've integrated with Fly.io to autoscale your web and worker machines. You'll be able to link your Fly apps with Judoscale, and setup your process groups to autoscale machines based on queue metrics or on a schedule.
Our getting started with Fly.io doc is ready for you to give it a try!
We're now tracking processes/services that go missing on the platform and identifying them in the UI so you can take action.
Sometimes a service may be retired, renamed, or replaced with a new one, which means Judoscale would still be referencing the old one and no longer be able to autoscale.
Now we'll detect and surface that, sending you an email if the missing service had autoscaling enabled, so it can be reviewed and unlinked from Judoscale. Any new services will continue to show up automatically, so you can enable autoscaling on them as needed.
You can now view up to an entire week of your autoscaling and queue time history!
We've just released our new integration with the Railway platform. You'll be able to link your Railway project environments to Judoscale, and start autoscaling your service instances in no time.
We've changed our pricing structure for our "direct" integrations (all integrations except Heroku).
Previously, we billed based on metered CPU usage, and it wasn't great for anyone. Customers couldn't reliably predict their bill, and we were losing potential customers because of our confusing pricing.
Our new pricing mirrors our Heroku pricing—fixed monthly plans based on your "maximum scale". You'll know exactly what monthly price you'll pay depending on your scaling needs.
Our new plans are listed here along with a simple calculator to know exactly which plan is right for you.
Autoscaling down to zero instances is a great way to avoid wasteful spending on worker services that often sit idle.
We've always allowed Heroku worker processes to scale to zero, and now you can do the same with your Render worker services. Render doesn't actually permit "scaling to zero"—instead you need to suspend a service.
Judoscale handles this for you behind the scenes. When scaling a worker service to zero instances, we're actually suspending it for you. And when we scale back up, we resume the service.
So go ahead and let those worker services scale to zero! You'll reduce your hosting bill, and Judoscale will make sure they scale back up when needed.
Render recently launched projects and environments as a way to organize your services (similar to "apps" on Heroku). Now you can link these project environments to Judoscale.
Judoscale will link all of your Render services in the chosen project environment.
Not only does this keep your Render services organized in Judoscale—it also opens up our existing maintenance mode feature to Render users.
Note that you can no longer link "ungrouped" Render services to Judoscale.
Continuing the improvements to our setup & onboarding, we are introducing the option to change workers autoscaling to use queue depth, i.e. the number of jobs in any given queue (or set of queues).
By default, Judoscale will start with job queue time, our recommended way to autoscale. However, some backends may not support collecting queue time (in which case we will already use queue depth), and some workloads may be better off autoscaling via queue depth. So, after the adapters have been setup and we start collecting metrics, you can jump back on the Setup and choose to switch your base autoscaling metric: (provided that the adapter supports collecting both.)
You can switch between queue time and queue depth at any point in time, just make sure you adjust your autoscaling target ranges accordingly.
