gem.coop

namespaces released

Sat, 06 Jun 2026 00:00:00 +0000

hi again everyone, we’re back with exciting news. namespaces on gem.coop have been promoted out of beta and into general availability. that means you can use namespaced gems directly from the top-level gem.coop domain, like this:

source "https://gem.coop/@kaspth" do
 gem "oaken", "~> 1.0"
end

if you don’t already have your own namespace, sign up to reserve yours today!

what about the beta.gem.coop namespaces and gems?

namespaces and gems are shared between gem.coop and beta.gem.coop, and the beta.gem.coop domain name is going to stick around permanently. this is both so your existing URLs will continue to work, and so we can use that domain to test other features in the future. for example, until we finish resolving all reported issues with cooldowns, we’re going to keep that feature on the beta domain.

what about cooldowns?

we have added support for cooldowns to every namespace. you can enable cooldowns by adding /cooldown to the end of your namespace url, like this:

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

thanks

we couldn’t have shipped namespaces out of beta without tireless development and infrastructure work by gem.coop members andré, kasper, david, josef, and olle.

many of the bugs that needed to be fixed were revealed by our extremely helpful testing group, including andrea, joel, marco, peter, stephen, thomas, and tim.

terms and policies

on top of getting namespaces out of beta, we have also been hard at work finishing our terms of service and writing the rest of our policies. so far, we have completed policies around conduct, security, copyright, name disputes. we’re several drafts in on our privacy notice, and we’ll post that soon as well.

what else have you been doing?

we’ve published a new faq answering the questions we’ve seen most often. there’s also a new roadmap listing our completed plans, our current tasks, and our future goals.

what’s next?

as the roadmap reveals, we’re currently working on fixing bugs in the cooldowns system, adding supporter subscriptions, and providing automation for “dev” releases of gems, allowing anyone to test a PR or the latest push without having to check out the git repo and build the gem locally.

we’ll be back with more updates as we finish all of those things that we’re working on. in the meantime, enjoy those namespaces and give us your feedback!

update #6: how namespaces work

Thu, 05 Mar 2026 00:00:00 +0000

We’re live in beta! Here are our next steps

Last week, we at gem.coop announced support for namespaces that you can publish to and use namespaced gems in Bundler today. Our original post outlines how namespaces improve package security, but in this post we’ll go through how to use them and how Bundler handles namespaced gems.

We’ve already had 166 people sign up to try the beta, and we have 175 namespaces live today. Thank you for trying us out! Please keep the feedback coming. You can sign up at gem.coop/sign_up

In the immediate term, we’re working on better support for gems that have been precompiled (we’ve had an overzealous gem version check when you push gems), but we’re pretty close to having it.

We’ve also been working on incorporating your feedback and we’ve already shipped a more detailed namespace profile and gem profile page. You can see an example of each here:

While these are early stages we’re intentionally aiming for these to be pages that you as a gem author would feel proud to post. Gem authors are also some of the most conscientious and discerning Rubyists around, and they’re typically plugged in to which gems they’d recommend others check out. We’re working on a lightweight recommendation system to help with that. This work is inspired by seeing what the team at rubyevents.org has been putting out, and helping Rubyists show off their work. It’s time gems, the backbone of so much of our day-to-day code, get the same loving treatment.

For now, all gem.coop namespaces are public and don’t require any authentication. We plan to allow namespaces to have private gems in the future, and those will require authentication. We’ll announce our roadmap soon, along with with what we’re thinking for free and paid plans and pricing.

How Bundler handles namespaces already

First, when you claim your personal namespace at https://gem.coop/sign_up, you get your own index that works just like the global gem.coop index, but it only includes the gems that you’ve published there. As an example, here’s the official namespace for gem.coop: https://gem.coop/@gem-coop

Next, to tell Bundler (and soon, rv) that you want to use gems from your namespace, wrap them in a source block in your Gemfile, like this:

source "https://gem.coop"

gem "global"

source "https://gem.coop/@myspace" do
 gem "personal"
end

This way Bundler knows to resolve and install personal through the @myspace namespace, while other gems should come from the global source.

If personal has any internal dependencies, Bundler will also pull those from the same @myspace source to protect from dependency confusion attacks.

Now what if personal and global share a common dependency like i18n? How do we resolve that ambiguity and prevent dependency confusion? A case like this:

source "https://gem.coop"

gem "global" # depends on i18n

source "https://gem.coop/@myspace" do
 gem "personal" # depends on i18n, too
end

What source should Bundler pick from to resolve i18n? The global source, or the namespaced one in @myspace?

Bundler will consider a namespaced source to rank higher in specificity over a global source, so i18n will still come from @myspace if it’s there.

But what if you’re using two namespaces, one for the organization you work for, and one that you published to your personal namespace, like this:

source "https://gem.coop"

source "https://gem.coop/@organization" do
 gem "business" # depends on i18n
end

source "https://gem.coop/@myspace" do
 gem "personal" # depends on i18n, too
end

If both @organization, and @myspace have versions of i18n, this case is ambiguous and Bundler doesn’t want to choose for you, since that could be insecure. Instead, Bundler errors out and tells you to declare gem i18n inside which source you want to pull it from.

This process of “resolving sources” requires querying the index for each source, to know which gem names are available, and then Bundler can move on to resolving gem versions. It’s recorded in Gemfile.lock, so it can be skipped the next time Bundler runs (if the lockfile is in sync with the Gemfile).

Next, let’s look at the HTTP requests that Bundler uses do all of this work.

How Bundler queries sources, resolves versions and installs gems

To give you more context for how Bundler works, these are the important routes and how Bundler uses them:

/versions — used to resolve which gems are in a source
/info/:name — to resolve which versions are available for each gem
/gems/:name-:version.gem — downloading a gem resolved to one version

`/versions`

https://gem.coop/versions (watch out, it’s ~20mb!)
https://gem.coop/@kaspth/versions

A text file of gem names + versions + hash of the current /info file.

The versions file is mostly append only, so Bundler can use HTTP Range requests to update the 20mb version of the global index incrementally.

When a new gem version is pushed, it goes on a single line at the end of the file like:

gem 2.0.0 abc123

Once a month or so, /versions files are compacted to combine versions, so the lines look like:

gem 1.0.0, 1.0.1, 2.0.0 abc123

If you’ve ever heard talks from the original Bundler maintainers mention the “Compact Index”, this is it!

`/info/:name`

An info file contains versions plus dependencies plus metadata. gem.coop outputs more metadata than RubyGems, like licenses, executables, and published_at time. This is to help us do further install-time optimizations that we’re experimenting with.

`/gems/:name-:version.gem`

Finally, when it comes time to install a gem, Bundler downloads a specific gem + version package from this route. If it’s already downloaded and installed, Bundler will skip querying for it.

Wrap-up

We’re thrilled about the encouraging response to our beta, and the trust the Ruby community is showing us. We’d like to keep earning it.

If you’d like to sign up for the beta to publish your own gems to your own namespace, you can do so at https://gem.coop/sign_up

Thank you for trying us out! Please keep the feedback coming. We’ll be here.

gem.coop update #5: namespaces beta

Tue, 24 Feb 2026 00:45:00 -0800

Today, the gem.coop team is very excited to announce we have reached public beta. If you want to get started right away, sign up now to start publishing your gems.

Have you ever come up with a really good gem name, only to discover that name has already been taken and you can’t push your gem? Ever been confused about if the gem aws-sdk-malware was really published by AWS?

Namespaces are the answer to these problems.

Our public beta offers anyone the chance to sign up, request a dedicated namespace for publishing gems, and even invite other users to collaborate in an organization.

It works by creating separate gem sources for each user or organization. So you can get our gems from gem.coop/@gem-coop, and you can publish your own gems at gem.coop/@yourname.

In addition to namespaces, we’re working hard on other features that you can’t get anywhere else. When the beta is complete, we plan to require a paid plan for namespaces and other exclusive features, like preview builds for every PR, precompiled gems for secure and fast installs, and more.

Sign up today to claim your namespace! Once you’ve tried it, give us feedback about the features you want to see from a gem hosting service.

announcing the 2026 Gem Fellowship

Mon, 02 Feb 2026 09:44:46 +0800

Last month I announced my latest venture to support the Ruby open source community: the Gem Fellowship. I want this grant program to support and fund existing Ruby-related open source project maintainers and their ongoing efforts: fixing bugs and adding features for those libraries we know and love.

The Class of 2026

We announced $100,000 in available funds, took applications in the month of December and received 40 applications for a total of $439,000 in requested funds. I’ve been working with gem.coop to select the highest value projects for the community; we settled on these eight projects.

Jeanine Adkisson https://github.com/rouge-ruby/rouge

Rouge was created in a fit of rage by jneen in an attic somewhere in south England when her personal website broke due to a libpython linking error in pygments.rb, which was the gold standard of syntax highlighting at the time. It has since grown into a formidable project, supporting over 200 languages and powering the syntax highlighting of Jekyll, middleman, and Gitlab among others.

Emiliano Della Casa https://github.com/emilianodellacasa/ruby-asterisk

Ruby-Asterisk is a Ruby client for the Asterisk Manager Interface (AMI) that relies on synchronous telnet connections. We are transforming it into a comprehensive toolkit for the Asterisk PBX ecosystem by adding native support for the REST Interface (ARI) and FastAGI. The project is undergoing a major architectural overhaul to leverage modern Ruby concurrency features like Ractors and Async, ensuring thread-safety and compatibility with Ruby 3 and the newest Ruby 4.

James Couball https://github.com/ruby-git/ruby-git

ruby-git provides a Ruby interface to the git command line. The current codebase, while functional, has several design issues that have accrued over time, making it difficult to extend and maintain. The goal of this project is to refactor the codebase so it can better evolve with the git command itself. See our Architecture Redesign Implementation Plan.

Piotr Murach https://github.com/piotrmurach/tty-markdown

TTY::Markdown transforms Markdown content into an easy-to-read format for display in terminal emulators. The grant will contribute to improving this experience through more robust content rendering with native hyperlinks, expanded theme configuration, greater recognition of HTML tags, and support for new elements such as emoji shortcodes or task lists.

Christoph Olszowka https://www.ruby-toolbox.com/

Christoph is the long-time author and maintainer of SimpleCov and Ruby Toolbox. This grant will support ongoing maintenance for his projects.

Marco Roth https://herb-tools.dev

Herb is an HTML-aware ERB parser and tooling foundation that treats HTML+ERB as a structured language rather than plain text. It provides a lossless syntax tree that enables reliable formatters, linters, language servers, and more advanced rendering and developer tooling in the Ruby ecosystem.

This grant will be used to stabilize Herb towards a 1.0-ready tooling and language foundation for Ruby, with a focus on backwards compatibility. It will also lay the groundwork for exploring reactivity support in the rendering engine.

Dmitry Vorotilin Cuprite, Ferrum

Ferrum and Cuprite provide a Ruby bridge to modern headless Chrome and the Capybara driver powering reliable browser-based testing. With this grant, Dmitry aims to ship Ferrum 1.0 with a stable, clean API and make Cuprite fully compatible so every Capybara test suite runs green on a fast, modern browser stack.

Jared White https://www.bridgetownrb.com

Bridgetown is a content-focused, “hybrid” web framework supporting both static deploys and full-stack applications. We’re ready to take things to the next level with two initiatives: an official plugin program called Bridgetown Center inspired by GNOME Circle, and a high-quality customizable theme called Willamette suitable for documentation, publishing, and portfolios.

Congratulations to our 2026 Gem Fellowship winners!

Finally, we want to thank all Fellowship applicants for their time and ongoing effort to build and improve Ruby software. We can’t fund everyone but we hope you will continue to help Ruby’s open source community thrive!

Background

Early in my Ruby days, I took over maintenance on the memcache-client gem. A year later Couchbase asked me if I would be interested in adding support for memcache’s new binary protocol; they would be willing to pay me to do the work. I accepted their offer and that work turned into the dalli gem which has benefited the entire Ruby community. The amount was $3,000, a laughably small amount IMO considering the actual amount of time I spent working on it. 500-1000 hours over the next two years? But the expertise I developed from that small stipend was absolutely critical to making Sidekiq into the high performance Rubygem which has been so valuable to the Ruby community. Everybody wins.

That’s the spirit in which I’ve created the Gem Fellowship.

Mike Perham, mike@contribsys.com

gem.coop update #4: cooldowns beta

Wed, 28 Jan 2026 11:20:00 +0800

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:

Ellen has been working on jwl, demonstrating several ways that gems could be simpler.
Olle did maintenance work on more repos than you can shake a stick at, including a big testing PR to ActiveRecordQueryTrace.
Martin built the Skillet CLI tool to run Claude Skills as shell scripts.
André (with lots of help from David) worked on the new rv clean-install command, which works like bundle install --frozen.
David also fixed countless bugs in rv, ensuring that installing ruby, installing gems, and compiling native extensions all work as expected.
Samuel built and shipped the arctic gem, providing frozen strings from ENV to save on allocations.
Josef has been investigating the new RubyBox feature in Ruby 4.0.
Kasper, our newest member, released 1.0 versions for his Rails extensions Oaken, Associated Object, Stashed Redirects, and Performs.

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!

gem.coop update #3: thank you

Thu, 27 Nov 2025 13:10:00 -0800

Over the past few months, a lot has changed. Our team has grown closer together, the appetite for innovation in Ruby has skyrocketed, and in every part of the Ruby community we’ve seen more engagement and collaboration.

Ruby cracked open a little and the community stepped in to fill the gaps.

We’re reaching out to let you know that we are all grateful for your support. We’re excited to see what we can make together.

Thank you.

P.S. At SFRuby Conf, Mike Perham (@mperham) announced the Gem Fellowship, a grant partnership between gem.coop and Contributed Systems to provide $100,000 in grants for each of the next three years. We can’t wait to see what you build!

the gem fellowship

Thu, 20 Nov 2025 00:00:00 +0000

From guest author, Mike Perham (@mperham), creator and maintainer of Sidekiq.

I’m happy to announce the Gem Fellowship, a grant partnership with gem.coop, the new open source cooperative in the Ruby community. Contributed Systems, my company behind Sidekiq Pro and Sidekiq Enterprise, is committing to provide $100,000 in grants for each of the next three years. These grants are meant to provide funding to the altruistic people who maintain and improve the open source tools freely available to the Ruby community.

Quick Details

These awards are meant for existing projects, this is not meant as seed funding for the creation of new projects.
People can apply during the month of December 2025.
Decisions and notifications will follow in January 2026.
Applications will be reviewed by four active members of gem.coop plus @mperham.
Grants will be awarded in increments of $2,500.
The maximum award for a single project is $25,000.
A minimum of 5 different projects will be funded.

FAQ

Q. What are grant winners required to do?
A. Your grant proposal in December should have a description of the work you’d like to perform and a requested grant amount. The award committee will reach out if your proposal is accepted. You do the work. You then email a final work summary with payment details once the work is substantially complete; we will verify your work and pay out the agreed stipend within one month.

Q. Can other companies add additional funds to increase the size or number of Fellowships?
A. Yes! Gem.coop wants to represent the broader open source Ruby community, and we would love to increase the impact of this program with support from your company.

Q. Can a project publicly blog or link back to their Gem Fellowship?
A. Yes! We will publish a page annually with the list of winning projects which you can link in your README, for example.

Q. Can I apply if I don’t own the project I want to work on?
A. You should clearly document that the project is interested in mentoring you or accepting your completed work. Like any open source contribution, it’s best if you open an issue and discuss it with the team.

Q. Can I apply if I am an individual?
A. These fellowships are intended for individuals, so yes!

Q. Can I apply if I live outside the United States?
A. Yes, but we need to be able to pay you somehow. If your proposal is accepted, we’ll be in touch regarding payment. If there are payment concerns, please note any issues in your proposal.

Q. Who’s deciding?
A. Mike Perham, David Rodrígeuz, Josef Šimánek, Martin Emde, and Ellen Marie Dash are the five who will judge. All are long-time open source contributors to the Ruby community.

gem.coop update #2

Tue, 18 Nov 2025 22:42:27 -0800

Hi everyone. We’ve heard that you want to know what we’re up to, so we’re writing to keep you all up on the latest.

Since we last wrote, we have continued our governance plan. Before voting to elect leadership, we decided to eliminate the single “Project Leader” role, to align more closely with the way we have worked together in the past. Once that change was made, we held nominations and elections for the Project Leadership Committee.

We are happy to announce that the contributors to RubyGems.org in the last 12 months have elected the first gem.coop Project Leadership Committee, with members @martinemde, @indirect, and @duckinator. Next, we’ll be working together to set up the official list of Maintainers, and selecting the Technical Leadership Committee from those maintainers.

We are also excited to report that we have finalized a contract with Fastly to participate in their Fast Forward program, meaning our CDN infrastructure is now being donated by Fastly. Thank you very much to Fastly for their consistent support of open source infrastructure.

With those important start-up items now much farther along, we’re looking forward to turning more of our attention and focus to shipping new features. As always, if you’re interested in contributing, asking questions, or just hanging out, you’re welcome to join the Bundler Slack and chat with us in the #gem-coop channel.

Until next time,
The Gem Cooperative Team

gem.coop update #1

Wed, 05 Nov 2025 16:04:27 -0800

Hello from the gem.coop engineers!

This is our first newsletter. We’ll be sending these out whenever we feel there’s something useful to say, to keep you all updated on our progress. You can follow along via email or via RSS feed at https://gem.coop/index.xml. If you were forwarded this email and you want to sign up, go to gem.coop and enter your email there.

Traffic report

In October, gem.coop served

17,233,484 requests
1,410 GB of data
for $243 total

That’s quite a lot of gems! Thanks for trusting us as your gem server. It’s exciting to see so many people using gem.coop and we can’t wait to introduce some of the new features for the community.

Governance progress

We have open-sourced our governance documents and processes, based on Homebrew’s governance, at github.com/gem-coop/governance. We are following a public bootstrapping process, and so far we have offered voting membership to everyone Mike McQuaid listed as writing, approving, or merging at least one pull request to RubyGems within the last year, using the brew contributions CLI tool.

Our next step is for everyone who agreed to vote to actually use those votes to choose the members of the Project Leadership and Technical Steering groups.

Infrastructure & hosting

We launched gem.coop using Fastly’s Edge Compute, and it has worked extremely well so far. During October, we applied to join the Fast Forward program at Fastly, which provides free hosting for open source projects, including RubyGems.org, PyPI, Rust’s crates.io, the Curl project, and many others. We found Fastly to be reliable and helpful partners when we worked with them on RubyGems.org, and we are looking forward to working with them again on our new efforts.

Coming up next

We have a lot of ideas! We’re working on experiments around faster indexes and gem installation, offering namespaced gem servers for existing gem clients, and building client support for multiple gem namespaces inside a single server.

If you’d like to participate, we have created a channel in the Bundler Slack named #gem-coop that is open to everyone. We would love to discuss or work together on ideas for the future of gem hosting. It’s also the first place you’ll hear about some of the things we’re testing.

See you next time,
The Gem Co-op Team

introducing gem.coop

Fri, 03 Oct 2025 00:00:00 +0000

We’re excited to introduce gem.coop – a new server for gems in the Ruby ecosystem.

We aim for fast, simple hosting, that is compatible with Bundler but optimized for the next generation. It’s built for the community by the former maintainers and operators of RubyGems.org.

All gems published to RubyGems.org are available, updated in real time. Get started right now with a simple change to your Gemfile:

-source "https://rubygems.org"
+source "https://gem.coop"

If you want to follow along with our progress, subscribe to the gem.coop newsletter for monthly updates.

Our goal is to provide fast, community-owned, transparent, sustainable, and secure gem hosting for everyone. We’re launching with support for bundling and installing all public gems, and we’re excited to keep improving.

— The Gem Cooperative (@deivid-rodriguez, @duckinator, @indirect, @kaspth, @martinemde, @olleolleolle, @segiddins, @simi)