Judoscale Changelog

We just launched Judoscale for Northflank. Connect a team-scoped API token, link a project environment, and Judoscale can scale the instances on your combined and deployment services. That includes Northflank Cloud and bring-your-own-cloud projects.

Northflank already autoscales on CPU, memory, and requests per second. Those signals tell you how hard the containers are working, not whether requests or jobs are waiting. Judoscale scales on request queue time for web services and job queue latency for workers, so Sidekiq, Celery, BullMQ, and the rest react to backlog. Schedules and per-service controls are included.

Learn more in the getting started docs.

The Judoscale Team API is here! Manage your team, apps, processes, autoscaling settings, and schedules programmatically. Read metrics, scale events, and restart events for your apps.

Authenticate with a team API token. The docs include an interactive reference and an OpenAPI spec.

API reference →

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.