Making sense of your JUDOSCALE_URL env vars

When setting up a new service in Judoscale, we’ll prompt you to set the JUDOSCALE_URL env var. It’ll look something like this, depending on your hosting platform:

Why are JUDOSCALE_URL values shared between services?

Most of the time, all of your services in a group will have the same JUDOSCALE_URL, but sometimes they don’t.

Let’s break this down piece-by-piece:

• The provided JUDOSCALE_URL env var includes what we call an adapter token.
• The adapter token is how the Judoscale backend associates metrics with a given service (or “app” or “process”, depending on your hosting platform).
• Most of the time, all services in a group (all processes in an app) use a shared adapter token. This means metrics reported by all services in the group are combined. With multiple background worker services, it’s the selected queues that disambiguate those metrics among worker services.
• By sharing an adapter token, we can allow worker services to scale down to zero. A service that’s completely scaled down won’t be reporting any metrics at all, but we can use the metrics reported from “sibling services” to determine when to scale back up.
• When a group has multiple web services, they can’t all use the shared adapter token because we’d have no way to disambiguate those metrics (web metrics don’t have named queues). In that case, each web service after the first one is given a dedicated adapter token (and a dedicated JUDOSCALE_URL).

So, it all comes down to whether you have multiple web services in a group (app, cluster, etc.).

How can I see which JUDOSCALE_URL values are shared?

Depending on your hosting platform, you probably don’t want to duplicate shared ENV values for each service—you want to use something like Render’s env groups to set them once and reuse them for each service. And while you could go into the “setup” wizard for each service to find the JUDOSCALE_URL, that’s super tedious!

Instead, you can find all of your JUDOSCALE_URL values listed together by clicking the “edit” link for a given group or app:

This page lists all available services—it’s where you link new services and unlink services you don’t want to see in Judoscale. It’s also where you can get a birds-eye view of all JUDOSCALE_URL values:

From here, you can decide how best to set up your ENV vars—which ones can be shared and which ones must be dedicated per-service.

Forcing a web service to use the shared adapter token

You might notice in the previous image that one web service is using the shared token and one is using a dedicated token. This all depends on which web service was linked first.

If you want to change which web service uses the shared token, you can unlink and relink both of them. When relinking, the first web service to be linked will get the shared token. Here’s a quick demo:

Using shared tokens in a legacy Render integration

Our Render integration looked very different before we added support for projects and environments. If you have a Render service added to Judoscale before November 2024, you might see adapter tokens that look like this:

These adapter tokens are not generated by Judoscale—they are the service ID’s provided by Render—and it means that every service has a dedicated adapter token. If you’ve been following along above, you might realize that this also means these worker services cannot scale to zero because we’d no longer be receiving metrics for that service and wouldn’t know when to scale back up.

That’s a pretty important Judoscale feature, and you’ll need to regenerate your adapter token to use it. How do you do regenerate your token? Unlink and relink those services, just like in the short demo above.

Note that autoscale must be turned off to unlink a service, and you’ll need to set the JUDOSCALE_URL env var in Render after relinking. Once you have multiple services with the same JUDOSCALE_URL, you should be able to autoscale down to zero.