Judoscale Changelog

We now support autoscaling Next.js with a dedicated judoscale-nextjs adapter!

This is for self-hosted, long-lived Node (next start or equivalent) on Heroku, Render, Railway, Fly.io, Scalingo, and Amazon ECS. It does not support Vercel serverless or the Edge runtime—those don’t have a long-running process for the reporter.

Setup uses Next’s instrumentation.ts hook, so every request (App Router, Pages, Route Handlers, RSC) is instrumented without framework middleware.

Install guide →

We just launched Judoscale for Scalingo, the European PaaS that feels a lot like Heroku. Push your code, get containers and managed databases, and run in Paris datacenters with GDPR, ISO 27001, and HDS certifications built in. If you’re shipping Rails, Node, Python, or Java and want a real PaaS instead of a DIY cluster, Scalingo is a solid home for your app.

Scalingo already supports horizontal scaling and a native autoscaler based on CPU, memory, response time, and traffic. Those metrics are useful, but they’re indirect: they tell you how hard your containers are working, not whether users or jobs are waiting. Judoscale scales on request queue time for web and job queue latency for workers, so Sidekiq, Celery, BullMQ, and friends react to backlog instead of CPU warmth. Schedules and per-container-type controls are included.

Link a Scalingo project, pick an app, and you’ll be autoscaling in minutes. Getting started docs are ready, and if you want the full pitch, visit our Scalingo landing page.

Team members now have a role: Member or Admin. Members get full access to the team’s apps and autoscaling. Admins get all that plus managing the team itself — settings, subscription, members, and the new team-wide 2FA requirement.

Admins can require two-factor authentication (2FA) for the whole team in one click. Anyone without it will be asked to set it up at their next sign-in.

Read more in our team management docs.

We’re rolling Dyno Sniper out to all customers running on Heroku, after running successfully in early access on our own production apps (and a few customers) for some time.

It complements autoscaling by automatically detecting and restarting poorly performing dynos — the kind that get stuck on noisy hardware and drag down your queue time (or response time), even when the rest of your fleet is fine.

Find it under your web process’s advanced settings:

Restarts show up directly above the scale chart. Hover any marker to see which dyno was sniped:

Learn more.

The Queue Time and Response Time charts now have a per-instance view that shows each web dyno / instance individually. Click the chart label to switch between the average view and the per-instance view.

Hover the chart to view each instance’s value at that moment in time, sorted highest first — handy for spotting if it’s a fleet-wide spike or maybe a specific instance that might be misbehaving.

Head to the app to view your app’s per-instance chart breakdown.

Our charts have always shown date/time stamps using your local (browser-based) time zone, but the schedule has been UTC-based since the beginning. Now both speak the same time zone: yours!

The schedule is now displayed matching the charts time zone, which can be configured in your user settings or directly in the chart overview, so you can choose a specific time zone to see both the charts and schedule across the board. This only affects your view.

The schedule can also be anchored to a specific time zone (UTC by default), and is going to be daylight saving time-aware, so it will adjust accordingly as clocks change. The time zone is set is per-process, so you can have a different one on each process if needed.

Check out the documentation for more info.

Want to compare hosting costs across PaaS platforms?

If you visit your application settings you’ll see a new card near the bottom with a “Launch Pricing Calculator” button.

This launches our PaaS Pricing Comparison Calculator pre-filled with your app’s processes.

Worker process scaling charts now include a “Busy Jobs” row that shows when your background workers had active jobs running.

This row appears when you have the Prevent downscaling when jobs are busy setting enabled, helping you see at a glance when job activity might be preventing downscaling.

You can enable two-factor authentication using time-based one-time passwords in Judoscale now.

Head over to your user settings to enable it.

Our judoscale-python package just got native support for the Dramatiq background task processing library.

It only works with the Redis broker (for now). I’s fairly simple to setup, and you’ll be autoscaling your dramatiq workers in minutes!