Adam McCrea

Here's our write-up on the WHY and HOW of this whole goofy experiment.

judoscale.com/blog/rails-...

If I was responsible enough to do any sort of ROI calculation, this never would have happened. Instead, we went all-in on RailsConf with 15 homemade videos and a custom local-only app to run our booth. I'd do it all over again.

I love my job

As requested by absolutely no one, a supercut of every kazoo clip we made for #railsconf2025

Really hope we don’t get kicked out of the last #railsconf for bringing kazoos 🎶

Visit our booth at #railsconf to get your kazoo! Watching us make fools of ourselves is just a bonus.

Who’s ready to party? #railsconf #kazoos

If it’s not at least a little bit cringe, we didn’t go far enough. #railsconf #kazoos #marketing

Marketing technique #77: Humiliate yourself for attention. #railsconf #kazoos

Y’all this is only the beginning. Buckle up! #railsconf #kazoos

That’s where proactive autoscaling comes in. By targeting, say, 60% utilization, you’re building in 40% headroom for unexpected spikes. You’re trading efficiency (and some cost) for reliability.

🧠 More on the differences and trade-offs: judoscale.com/blog/introd...

Most autoscalers are reactive—they respond to traffic after it spikes. That’s usually fine… until it’s not.

If your app gets hit with big surges of traffic all at once, even the fastest queue-time autoscaler might not spin up capacity in time to avoid slowdowns or timeouts.

One week until #railsconf! The whole Judoscale team will be there with... kazoos?

When budget is tight Fly is definitely the way to go! Glad the calculator was helpful!

Python task queue pro-tip: Autoscale based on queue latency, not CPU!

Your task queue can back up without CPU spikes, leaving you in the dark.

Check out Jeff's full Celery & RQ comparison here:
judoscale.com/blog/choose...

Choosing a Python task queue? Jeff Morhous compared Celery vs RQ:

🧠 Celery: Feature-rich but complex

🚀 RQ: Simple & easy to deploy

Jeff's advice: Most apps do fine with RQ until they need more horsepower. Then consider making the switch to Celery.

🔌 Big news! Custom platform integrations coming soon to Judoscale! Create your own adapter, keep your infrastructure, get all the autoscaling magic.

Message me if you want early access.

What platform would you connect with?

This behavior is confusing at first, but it's actually super cool once you wrangle it.

And with autoscaling in place, we don't really need to worry about it. New machines are being created with fresh burst balances when needed, spreading the load allowing balances to rebuild.

But why do they perform so well at first, only to fall apart after a bit?

It's the bursting!

Shared machines have a "burst balance" where they can use 100% CPU. Once the balance is depleted, CPU is throttled to 1/16.

I finally answered my questions about shared CPUs on Fly.io:

- How are they so cheap?
- Why do I need so many of them?
- Why does perf tank after 10 minutes?

Turns out it's well-documented: "shared" machines only get 1/16 of each CPU!

fly.io/docs/machin...

Fly is working nicely for us, although our main prod app is still running great on Heroku and we're in no hurry to move.

This is the exact config I landed on last week, and it's been a night-and-day difference with our 800 RPS app running on Fly. 🚀

Learn more: fly.io/docs/refere...

⚠️ It's a mistake to ignore these configs. The defaults are NOT what you want.

EXAMPLE: A 4-process, single-threaded web server should use a hard limit of 4 since that's the max concurrent requests. A soft limit of 1-2 would help route requests to less busy machines.

🧸 soft_limit: Traffic to a given machine is deprioritized when the soft limit is met.
🪨 hard_limit: Traffic to a given machine is STOPPED when the hard limit is met.
🔧 concurrency type: How concurrency is measured. Should be "requests" for web servers. NOT THE DEFAULT!

Last week I dug into HTTP routing behavior on Fly.io, and it's so cool!

Unlike random routing on platforms like Heroku, Fly can intelligently route requests to machines based on a load. Here are the configs you need to know...

If you have more than one worker process sitting idle while the job queue is empty, you're throwing away money.

And for queues with an SLO > 30 seconds, that number drops to zero.

I agree on all of your points, and I'm an employer who *does* send employees to conferences.

My point is about how you pitch it to your boss, and I think the "education" angle is a bad pitch.

I don't think it is. If you want horizontal scaling, you need to separate your data stores from your web/worker services.

For sure! I agree there's a lot of value in that.

"Does Rails 8 truly make platforms a thing of the past? And can small to medium-sized teams really save money by self-hosting?"

Preech it, Jeff! From the Honeybadger blog: www.honeybadger.io/blog/rails-...