Autoscaling on Heroku Fir: Your Options Today in 2025

Heroku has just launched their latest platform—Fir—and it’s their biggest launch in a decade. Built on Kubernetes and featuring expanded dyno options, cloud-native buildpacks, and integrated OpenTelemetry, Fir represents a significant evolution for Heroku. However, if you’re planning your migration to Fir, you’ve probably noticed something missing: autoscaling.

If you’re thinking, “Wait, no autoscaling? How am I supposed to manage my dynos?"—you’re not alone. Heroku is certainly hard at work on their own autoscaler for Fir, but your production apps can’t wait. Let’s explore how to autoscale on Heroku Fir today.

Is autoscaling optional?

Let’s face it—you could run your Fir app without autoscaling. Just drag those dyno sliders up until you’re reasonably confident you won’t get request timeouts or backed-up job queues.

This approach works great if:

1. You enjoy getting paged at 3 AM when traffic spikes
2. Your engineering budget is unlimited
3. You like explaining to your boss why your hosting bill doubled this month

Okay, okay… no need to get snarky. 😇

Not only will you waste money on idle dynos during low-traffic periods, but you’ll also miss the critical safety net that autoscaling provides. How many developers have confidently said, "Four dynos should be plenty!” only to discover during a traffic spike that they needed eight?

Without autoscaling, you’re stuck with two less-than-ideal approaches:

1. The “better safe than sorry” approach: Provision enough dynos to handle your highest possible traffic… and watch them sit idle 90% of the time. Your app is responsive, but your finance team is questioning your life choices.

2. The “we’ll scale when it hurts” approach: Start with minimal dynos and add more reactively when things break. Hope you enjoy those late-night deploys and apologizing to customers!

If you’re nodding along, you’ve probably lived this pain. The obvious solution—autoscaling—does exactly what you’d expect: automatically adjusts your dyno count based on actual demand, not guesswork.

Judoscale: The First Autoscaling Add-on for Fir

Unlike the Cedar stack you’re familiar with, Fir doesn’t ship with built-in autoscaling (yet). But here’s the good news: Judoscale has you covered from day one. We’re the first Heroku add-on to support Fir—in fact, we’ve been working with it since the earliest beta program.

What makes our approach different from other autoscalers you might have tried?

• We obsess over the right metrics: We don’t use CPU or response time (which can be misleading). For web dynos, we track request queue time—how long requests wait before processing. For worker dynos, we monitor job queue latency. These are the metrics that actually correlate with user experience.

• We’re fast—really fast: While traditional autoscalers might take 2-3 minutes to respond to a traffic spike (an eternity in web time), Judoscale checks your metrics every 10 seconds and can start scaling within seconds of detecting a change.

• We give you visibility and control: Our dashboard shows you exactly why scaling decisions are made, with intuitive visualizations that help you understand your app’s behavior over time.

• We’re developers building for developers: We’re a small team focused exclusively on solving this problem. When you reach out for help, you’re talking directly to the people who built the product.

Here’s how our approach translates to what you actually care about:

Setting up Judoscale on Heroku Fir

The good news? If you’ve used Judoscale before, the setup process on Fir is identical to what you’re used to. If you’re new to Judoscale, you’ll find it’s as straightforward as any other Heroku add-on.

Step one: Add the add-on to your app. You can use the Heroku dashboard or CLI:

heroku addons:create judoscale -a your-app-name

Then open the dashboard to configure it:

heroku addons:open judoscale -a your-app-name

Here’s what you’ll see:

The dashboard will display your Heroku app’s processes. To start collecting metrics, you’ll need our adapter library for your language. We support Ruby, Python, and Node.js—just click “set up autoscaling” and follow the language-specific instructions.

After you deploy your app with the adapter installed, you’ll see your metrics start to appear.

Now for the fun part—enabling autoscaling! Review the default settings (we’ve fine-tuned these based on hundreds of apps) and adjust your scale range:

• Min dynos: The floor Judoscale won’t scale below. For production web dynos, we recommend at least 2 for redundancy. For less critical workers, you might go as low as 0.
• Max dynos: The ceiling Judoscale won’t exceed.

Click “save settings and enable autoscaling,” and you’re done! Judoscale will now monitor your application and adjust your dyno count as needed.

Autoscaling for free

If you’re worried about cost, I have good news: you can try Judoscale without spending a dime.

Our White Belt plan is free forever and includes 20 autoscale events per month. That’s perfect for:

• Testing in staging environments
• Small projects with predictable traffic
• Getting familiar with how autoscaling works on Fir

For production apps, most teams upgrade to one of our paid plans to get unlimited scaling events and more advanced features. But here’s the thing: even our paid plans effectively pay for themselves. Almost every Judoscale customer saves more on their Heroku bill than they spend on Judoscale.

Ready to autoscale on Fir?

Don’t let the lack of built-in autoscaling hold back your migration to Fir. Install our free add-on in just 30 seconds and see for yourself how much easier capacity management can be.

Have questions about how Judoscale works with your specific Fir app architecture? Email us or schedule a call with our team. We’re developers too—we’ve been through our own Fir migrations and are happy to share what we’ve learned along the way.