a private RubyGems server that remembers
Point gem and Bundler at gastropod: a caching proxy for
rubygems.org, a hosted home for your own gems, and the part a plain gem server leaves
out — every install is verified at intake, correlated to advisories, and recorded,
attributed to whoever ran it.
connecting is as easy as
gem sources --add https://USER:TOKEN@gastropod.io/gem/ bundle config set https://gastropod.io/gem/ USER:TOKEN
gem install, bundle install, and CI work
unchanged once the source is added.
what happens on every install
- Identity is fixed. The gem resolves to an exact PURL, version, and sha256 digest, not just a name and a version constraint in a Gemfile.
- Integrity is checked at intake against the gem's published digest, before it's served.
- Advisories are correlated. Known OSV advisories attach to the exact version and map across everything downstream, including transitive Bundler dependencies.
- The install is recorded. Which principal pulled which gem, when, and from where, on the audit spine and exportable.
- It's remembered. SBOM, findings, and where-seen history stay on the digest for every later install.
a maintainer account is the whole perimeter
In August 2019, a compromised maintainer account pushed backdoored
versions of the rest-client gem straight to rubygems.org: legitimate signed-in
access, no exploit required, and every bundle install against an affected
version pulled malicious code with the same trust as the real thing. That's the structural
risk in any registry that resolves purely by name and version — a hijacked account or a
typosquatted lookalike looks identical to the genuine article until something actually
checks. Gastropod checks at intake: every gem is pinned to its digest before it's served, so
a later swap under the same name and version doesn't silently propagate, and identity
mismatches are flagged rather than passed through. If a bad version does get out, the
blast-radius graph and pull history answer which of your services pulled it, in minutes
instead of a source-tree grep across every Gemfile.lock you own. Private gem names resolve
from a hosted repo through the same URL, so a public lookalike on rubygems.org can't shadow
an internal name either.
proxy, hosted, virtual
proxy
A caching mirror of rubygems.org. The first install fetches and verifies into content-addressed, deduplicated storage.
hosted
Your own gems, pushed with standard gem push,
private by default with reader and publisher roles.
virtual
One source URL aggregating both, so a single
gem sources entry covers public and private resolution.
Every feature is on every tier: OIDC SSO, scoped tokens, SBOMs, blast radius, and audit are all present starting at our published rates.
FAQ
how do I add gastropod as a gem source?
gem sources --add with the gastropod URL and a token embedded
as basic auth, or bundle config set for Bundler. Both pick it up like any
other gem source, no plugin required.
does this work with Bundler and Gemfile.lock, not just gem install?
Yes. Bundler resolves through the same source URL, so
bundle install and bundle update get identity, advisory
correlation, and audit on every transitive dependency, not just top-level gems.
can I publish internal gems?
Yes. Standard gem push to a hosted repository, private by
default, with reader and publisher roles enforced per token.
does gastropod check gem integrity?
Gems are verified at intake against their published digest, and identity is pinned to that digest, so a version swapped after the fact can't inherit another gem's record.
can it run alongside Gemfury, Geminabox, or our current gem server?
Yes. Both gem and Bundler support multiple sources natively, so
gastropod can serve one project or team during evaluation while the existing server keeps
serving the rest.
Part of the full product overview. Also speaking: npm · PyPI.
RubyGems and Ruby are trademarks of their respective owners. Gastropod is not affiliated with the Ruby community or Ruby Central. Details current as of July 2026.