gem.coop Tests Dependency Cooldowns as Package Ecosystems Move to Slow Down Attacks

The Gem Cooperative, a community-run Ruby gem server launched last year by former RubyGems maintainers, has begun testing a new “cooldowns” feature that delays access to newly published packages. The project was created as an open, maintainer-led alternative to RubyGems.org and has since become a testing ground for ideas around governance and package infrastructure.

The new cooldowns beta enforces a 48 hour delay between when a gem is published and when it becomes installable. While simple in concept, cooldowns have emerged as one of the most effective defenses against modern dependency attacks, many of which are discovered and removed within hours or days of release.

Over the past year, cooldowns have increasingly moved from best-practice discussions into mainstream tooling. Dependabot and Renovate both support configurable waiting periods, while package managers like pnpm and uv have introduced mechanisms to exclude or delay newly published releases. These features reflect a shared conclusion across ecosystems: most large-scale dependency attacks succeed not because they are sophisticated, but because they spread quickly.

Implementing Cooldowns at the Registry Level#

Most cooldown mechanisms today live in client tooling, such as dependency update bots or package managers that refuse recently published releases. gem.coop’s beta takes a different approach by moving the delay into the registry itself, testing whether a curated, time-delayed view of the ecosystem can reduce exposure without relying on per-project configuration.

gem.coop’s cooldown server essentially delivers a delayed view of the Ruby ecosystem. Newly published gem versions are hidden for 48 hours, reducing exposure during the narrow window when malicious releases are most likely to spread before detection and removal.

Cooldowns are served from a separate beta endpoint at beta.gem.coop/cooldown, allowing projects to opt in by changing their gem source without affecting the main gem.coop registry.

Projects that need immediate access to newly released security fixes can bypass the delay by selectively pulling dependencies from the primary gem.coop source. The gem.coop maintainers describe this as an escape hatch rather than a recommended workflow, preserving flexibility without weakening the default protection.

The cooldowns beta builds on gem.coop’s broader efforts to rethink how Ruby package infrastructure is governed and operated. Since launching as a mirror of RubyGems.org, the project has focused on open governance, infrastructure sustainability, and experiments that reflect maintainer priorities. Cooldowns are the first fully shipped example of those experiments moving beyond governance and into supply chain behavior.

By shifting delay into the registry layer, gem.coop is exploring whether passive, infrastructure-level mitigations can reduce exposure without relying on perfect developer hygiene or universal automation. As dependency attacks continue to exploit brief windows of opportunity, we will see package ecosystems adapting to reduce exposure during those periods.