NEW! publish gems into your own dedicated namespace

gem.coop update #4: cooldowns beta

Jan 28, 2026

Hi again, everyone. We’ve got a big update for you, and we could use your help testing things out. If you just want to test the cooldowns beta, you can jump straight to the cooldown docs. The rest of this post has updates from the team, as well as more background on why we built cooldowns in the first place.

Recent work

Since our last update, we’ve been quite busy all around the Ruby ecosystem:

In addition to all of that work, we’ve also been experimenting with different ways of serving gems. Some of our experiments aren’t fully baked yet, and we’ll be back with more announcements soon. Today, we’d like to talk about our first fully baked experiment: cooldowns.

What’s a cooldown

The concept of cooldowns is probably best explained in William Woodruff’s blog post We should all be using dependency cooldowns. The short version is that waiting a couple of days before upgrading your dependencies is a very effective security measure. Most compromised or malware-loaded packages are discovered and removed within a day or two. The very most sophisticated attacks (like the attack on xz) managed to avoid discovery for about 5 weeks, but attacks of that sophistication are extremely rare. As William points out in his post, just waiting 48 hours would have avoided almost all of the significant supply chain attacks from the last 18 months.

A few weeks later, William posted a follow-up titled Dependency cooldowns, redux. The follow-up post addresses the most common questions. The biggest question seems to be “if everyone does this, won’t that make doing it pointless?”. The good news is that even if every developer is using cooldowns, the security companies will still be scanning the latest packages. That means cooldowns are still an effective mitigation measure, even if no developers ever see the malicious packages.

Both Dependabot and Renovate clearly think this is a good idea, since they offer cooldowns as a feature you can configure. Something we realized while discussing the blog post is that it would be great to have a way for anyone to be able to wait. After a weekend of coding and a few weeks of bug hunting, we have a way for anyone to be able to wait.

We’re launching cooldowns as a beta feature, meaning it’s only available from beta.gem.coop. By offering new features on a different subdomain, we can make sure it’s easy to tell at a glance that there might still be issues. We also want to incorporate feedback from testing before we launch the final version.

Using cooldowns

The cooldown source has a 48 hour delay, and updates at least once every hour.

To use the cooldowns feature, ensuring that you aren’t able to see or install any gems that are less than 48 hours old, change the source in your Gemfile like this:

-source "https://gem.coop"
+source "https://beta.gem.coop/cooldown"

If you need to install any gems that have just been released with critical security fixes, you can do that too:

source "https://beta.gem.coop/cooldown"
gem "no-security-problems"

source "https://gem.coop" do
  gem "security-just-fixed"
end

By using the main gem.coop server as a secondary source, you can force the latest version of any gem, even if it isn’t cooled down yet. Don’t do that if you can help it, but it’s a good escape hatch to allow security fixes if necessary.

What do you think? Is 48 hours a good default cooldown time? Is a cooldown server helpful for you? Helpful for your company? How would you want to filter your gems? Let us know in the discussions on GitHub, or join the Bundler Slack and chat with us in #gem-coop.

Don’t forget to report bugs if you run into any issues!