The Ruby Toolbox ranks RubyGems by popularity and maintenance health

A catalogue that scores gems instead of listing them

The Ruby Toolbox is described as a catalog of all Rubygems that keeps track of popularity and health metrics to help you choose a reliable library, and the project description is more direct still: find actively maintained and popular open source software libraries for the Ruby programming language. The homepage is ruby-toolbox.com, and the repository holds the source code for that site. The distinction from a plain package index is the scoring. A list of gems tells you what exists; a list of scored gems tells you which of them deserve attention, and the metrics make the comparison explicit rather than leaving it to the reader's judgement of star counts and commit dates. The project is written in Ruby, is MIT licensed, the repository is not archived, and the last push was on 2026-10-17. There are no GitHub releases, so the repository history and the site itself are the record of the project. The topics place it in the Ruby ecosystem with a focus on developer tooling and web applications.

The stack: Ruby on Rails, Postgres, Redis and Vite

The application is a Rails application with the pieces a data heavy site needs. PostgreSQL is the database and Redis is used for background job processing, which is the mechanism behind the scheduled work of crawling gem and repository data. The Dockerfile for the production image confirms the shape, since it sets RAILS_ENV, RACK_ENV and APP_ENV to production, along with BUNDLE_DEPLOYMENT and BUNDLE_PATH, and excludes the development and test groups with BUNDLE_WITHOUT. Ruby itself arrives as a precompiled binary through mise, driven by the same pinned version files used for local development and CI, which are .ruby-version, .node-version and .mise.toml. The front end uses Vite, with vite.config.mts and vite-plugin-ruby in the dev dependencies, and pnpm for the JavaScript packages. The package.json lists Bulma for styles, Chart.js for charts, accessible-autocomplete, headroom.js and the Font Awesome and Lato font packages. The repository layout shows a conventional Rails tree with app/, config/, db/, lib/, spec/ and tasks/ directories, plus bin/, a Rakefile, a config.ru and a Guardfile.

Getting a development environment running with mise

The README is direct about the fastest route. The project provides a ready devcontainer configuration which you can use locally or on GitHub codespaces, and the .devcontainer/README.md is where the details are. For a plain checkout, the tool versions for Ruby, Node.js and pnpm are managed with mise, which also serves as the project's task runner, and after installing mise you run mise install inside your checkout to get the full toolchain.

The README then lists the running steps in order. You start postgres and redis, you install the project's dependencies and prepare the database with mise run setup, and then, optional but recommended, you import a partial production database dump using bin/pull_database, or you load some test data quickly with the fixtures task.

To pull repo data from the GitHub GraphQL API you need to provide a GITHUB_TOKEN, with the Github API Client configuration documented in doc/configuration.md. Finally you run the development processes, which are the web, worker and vite processes, with mise run server, and you reach the site at http://localhost:5000.

Running the tests, the linter and the git hooks

Beyond the server there is a full local quality workflow. You run the test suite with mise run test, and you check code style and security with mise run lint, with mise run format to auto-format. During development you can launch guard using bundle exec guard to continuously check your changes. The repo has overcommit git hooks set up to check changes before commit and push, and you set it up once with bundle exec overcommit --install. The README adds a detail that catches people out: whenever the hook config file .overcommit.yml changes, you need to verify its contents and approve the changes with bundle exec overcommit --sign. The sidekiq web UI is at http://localhost:5000/ops/sidekiq, with an empty username and development as the default password, which is the window into the background jobs that drive the catalogue updates. RSpec is the test framework, with .rspec and a spec/ directory, and .simplecov is present for coverage.

Data freshness depends on the GitHub API and on a token

This is where the project has a real operational dependency. The catalogue needs the repository data for gems, and the README says that in order to access the GitHub GraphQL API for pulling repo data you need to provide a GITHUB_TOKEN. Two consequences follow. The first is that the data behind a ranking is only as fresh as the last successful crawl of that gem, so a ranking tells you about a library as of a point in time rather than continuously. The second is that rate limits and token scope shape how much of the catalogue can be refreshed, which is a genuine operational consideration for anyone running an instance of this application rather than just using the site. The README also mentions an optional partial production database dump through bin/pull_database, which is the shortcut for getting a realistic dataset into a local environment, and the .env and .env.test files at the top of the tree are where the configuration differences live.

Deployment to fly.io and the production image

Production is documented separately from development. The doc/configuration.md file gives an overview of what needs to be set up to run the app in production, and doc/deployment.md covers how the production app on fly.io is deployed and operated, with the fly.toml file at the top of the repository holding the deployment configuration. The Dockerfile is written for that target, and it opens with a comment identifying it as the production image for rubytoolbox.com to be deployed to fly.io. It has a build and run section in the header.

#   docker build -t rubytoolbox .
#   docker run --rm -p 5000:5000 -e SECRET_KEY_BASE=dummy -e DATABASE_URL=... rubytoolbox

The image is built from ubuntu:26.04 and installs a small runtime package set including libpq for the pg gem, jemalloc for reduced memory fragmentation, libyaml and zlib for the precompiled Ruby, postgresql-client for database import and maintenance tooling, and curl for health checks. Ruby runs with YJIT enabled and jemalloc preloaded with a tuned MALLOC_CONF, and the build stage is deliberately throw-away to reduce the size of the final image.

Where The Ruby Toolbox is the wrong tool

There are clear boundaries and they are worth stating plainly for anyone tempted to embed it. First, it is not a package manager and it does not install anything. It is a catalogue with a search and scoring interface, and the resolution step is still bundler and RubyGems. Second, if you are looking for a single gem, the catalogue helps you choose but it adds a network round trip and a second opinion to something you could check directly on the gem page and the repository, and the metrics are only as good as the crawl that produced them. Third, running your own instance of the site is a heavy commitment for the problem: it needs Postgres, Redis, a background worker, a GitHub token and a scheduled crawl pipeline, and that is an operations team before it is a feature. Fourth, the scores are aggregate signals, and a library with a low score may be exactly right for a stable internal tool where maintenance activity does not matter, while a high score does not guarantee the library is appropriate for your constraints. The sensible alternative depends on the goal. For choosing a gem, reading the repository's commit history, the issue tracker and the gem's own release dates is a manual version of the same judgement. For automated dependency health checks inside a repository, an analysis tool that reads your own lockfile and reports on the gems you already depend on is a better fit, since it works from your manifest rather than from a global catalogue and needs no crawled database. The Ruby Toolbox earns its place as a discovery aid at the start of a choice, not as a permanent part of a build.

Editorial conclusion

Adopt The Ruby Toolbox if you are choosing a RubyGem for a project and want an independent signal about whether the library is still alive, since its popularity and health metrics are computed across the whole catalogue rather than from one vendor's page. Do not adopt it as a dependency in your own application, because it is a database application with a scheduled job pipeline, not a library you add to a Gemfile. Verify two things before you trust a specific entry: which metrics the entry is scored on and how recent the underlying data is, since the site tracks live repository data through the GitHub GraphQL API and an entry reflects the state of the gem at crawl time, and whether the gem you are considering is on RubyGems at all, since the catalogue covers RubyGems specifically. The practical first step is to read the entry for your candidate gem and compare its ranking with the repository itself before you commit to the dependency.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. rubytoolbox/rubytoolbox on GitHub