Judoscale Changelog

We’ve just released an assistant to help Heroku teams migrate from our Heroku add-on to one of our more economical Heroku direct plans.

It will copy over all your processes settings, and guide you to enable autoscaling on the new team. Check out the documentation to get started.

You now have the option to integrate with Heroku directly through Judoscale via OAuth, unlocking team level plans & billing, and slightly cheaper plans.

Same product, same features, different pricing. Learn how to get started with Heroku Direct, and check out our pricing docs for more info.

Utilization is a percentage representation of active processes handling web requests in your app. Nearing 100% utilization means almost all processes are actively handling requests almost all the time, which also means the app has very little room for handling traffic spikes without bringing in more processes.

You can use the utilization metrics to control autoscaling for your app, either on its own or combined with request queue time:

Read more about proactive vs reactive autoscaling and how utilization works in our blog, and check out the documentation to get started.

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.

Dive into our documentation to get started!

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.

Visit our docs to get started with Railway in Judoscale.

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.