Formats/Ruby Gems

Host and secure your private Ruby Gems registry

Ruby powers some of the world's largest applications, including Shopify's commerce platform. Cloudsmith gives Ruby teams a fully managed, private gem registry with built-in security scanning, upstream proxying, and granular access control - so you can ship gems with confidence.

Universal format support

Ruby Gems, plus everything else your teams ship. Cloudsmith is a secure, centralized store for all your packages, containers, and artifacts.

  • Use Ruby Gems + 30 other formats in one registry
  • Proxy and cache rubygems.org upstream packages for faster, more reliable builds
  • Store Docker containers and ML models alongside your gems in the same platform

How we support Ruby Gems

Cloudsmith gives Ruby teams a fully managed gem registry with the security controls, performance, and access management that rubygems.org simply cannot provide.
    Fully fledged Ruby Gems registry
    Cloudsmith works just like rubygems.org - use your Gemfile and Bundler exactly as you do today. Set your Cloudsmith repository as a source in your Gemfile, authenticate using Entitlement Token or HTTP Basic Auth, and install gems with gem install or bundle install without changing your workflow.
    Upstream proxying from rubygems.org
    Configure rubygems.org as a proxied upstream source so any gem not held in your private repository is fetched, cached, and served from Cloudsmith. Your builds stay fast and uninterrupted even when the public registry has availability issues, and cached packages are scanned before they reach your teams.
    Vulnerability scanning and policy enforcement
    Cloudsmith scans every gem for CVEs and malware on upload and on a continuous basis. Use OPA Rego-based policies to quarantine, block, or alert on packages with low, medium, or critical vulnerabilities - giving you full control over what reaches your build pipelines.
    OIDC, API key, and entitlement token auth
    Authenticate against your Ruby repository using Entitlement Tokens for read-only distribution, HTTP Basic Auth with an API key or password for publishing via gem push, or OIDC for keyless CI/CD authentication. Cloudsmith supports all major auth patterns so you can remove hard-coded credentials from your pipelines.
    Granular access control and team permissions
    Create public or private repositories and control access at the team, user, or token level. Distribute gems to external customers using scoped Entitlement Tokens with configurable download limits and expiry - without exposing your internal registry credentials.

Why teams choose Cloudsmith for Ruby Gems

Managing private gems without a dedicated registry means credentials in Gemfiles, no visibility into what your pipelines are pulling, and zero control when rubygems.org goes down. Cloudsmith removes every one of those gaps.
Without CloudsmithCredentials end up hardcoded in Gemfiles or committed to source control. Rotating them means updating every pipeline and developer machine manually, and leaked tokens are difficult to audit.
With CloudsmithCloudsmith Entitlement Tokens are scoped, revocable, and separate from your personal API key. Use OIDC in CI/CD to eliminate long-lived secrets entirely. Every token action appears in the full audit log.
Without CloudsmithYour builds depend entirely on rubygems.org availability. Any outage or rate limit hits every pipeline simultaneously, and there is no caching layer between your team and the public internet.
With CloudsmithConfigure rubygems.org as an upstream proxy and Cloudsmith caches every requested gem. Builds pull from Cloudsmith's globally distributed CDN backed by 600+ edge PoPs, so rubygems.org outages become irrelevant to your delivery pipeline.
Without CloudsmithOpen-source gems are pulled directly into builds with no inspection. Supply chain attacks on the public gem registry - typosquatting, dependency confusion, compromised packages - reach your teams with no warning.
With CloudsmithEvery gem, whether uploaded privately or fetched from an upstream, is scanned for CVEs and malware by Cloudsmith. Policy rules quarantine high-severity packages before they can be consumed, giving security teams the control that rubygems.org cannot.

Signs you're ready to switch to Cloudsmith for Ruby Gems

If your gem workflow relies on rubygems.org availability, stores credentials in source control, or gives you no visibility into what your pipelines are consuming, it is time for a purpose-built registry.
    No CVE scanning on incoming gems
    rubygems.org publishes gems as-is with no vulnerability or malware analysis. If your pipelines pull from the public registry without scanning, a compromised or typosquatted gem can reach production. Cloudsmith scans every artifact continuously and enforces policy before a gem can be consumed.
    Credentials scattered across Gemfiles and CI secrets
    Managing authentication for a private gem source without a dedicated registry means tokens in Gemfiles, secrets in CI environment variables, and no central revocation path. Cloudsmith gives you scoped Entitlement Tokens, OIDC keyless auth, and a complete audit trail of every access event.
    Build failures caused by rubygems.org outages
    Teams running high-frequency CI without an upstream caching layer are fully exposed to public registry outages and rate limits. Cloudsmith proxies and caches rubygems.org so builds remain stable regardless of external availability, and cached packages are served from the nearest edge PoP.
    No audit trail for gem consumption
    Without a managed registry, you have no record of which gems your pipelines pulled, when they were pulled, or by which service. Cloudsmith logs every push, pull, and policy event so you can trace exactly which artifact entered which pipeline - critical for compliance and incident response.
    Ruby gems siloed away from your other artifact types
    Maintaining a separate gem host alongside your Docker registry, npm feed, and Maven repository multiplies operational overhead and access management complexity. Cloudsmith consolidates all formats into a single platform - one set of policies, one audit log, one team permissions model.

Get started with Ruby Gems on Cloudsmith

Frequently asked questions

  1. Add a source block in your Gemfile pointing to your Cloudsmith repository URL. For Entitlement Token authentication use the format: source 'https://dl.cloudsmith.io/TOKEN/OWNER/REPOSITORY/ruby/' do gem 'your-gem' end. For HTTP Basic Auth with an API key, use: source 'https://USERNAME:API-KEY@dl.cloudsmith.io/basic/OWNER/REPOSITORY/ruby/'. Cloudsmith recommends passing credentials via environment variables rather than committing them into the Gemfile directly.

  2. Cloudsmith supports four authentication methods for Ruby repositories: Entitlement Token Authentication (recommended for read-only distribution and CI pulls), HTTP Basic Auth with your username and password, HTTP Basic Auth with your username and API key, and HTTP Basic Auth using a token credential. For CI/CD pipelines, Cloudsmith also supports OIDC authentication, which lets your build system authenticate without storing any long-lived secrets in your CI configuration.

  3. You publish to Cloudsmith using the standard gem push command. First, add your Cloudsmith credentials to your $HOME/.gem/credentials file - you can use the key name :cloudsmith: and then pass --key cloudsmith during the push. Alternatively, you can authenticate interactively when running gem push without pre-stored credentials. Cloudsmith also supports publishing via the Cloudsmith CLI, which is useful for scripted or CI-driven publishing workflows.

  4. Yes. You can configure rubygems.org (or any other upstream Ruby repository) as an upstream proxy on your Cloudsmith repository. When a gem is requested that is not in your private repository, Cloudsmith fetches it from the upstream, caches it, and serves it from your repository going forward. This means your builds are no longer dependent on rubygems.org availability and benefit from Cloudsmith's globally distributed CDN for faster pull times. Cached packages are also subject to your repository's scanning and policy rules.

  5. Yes. Cloudsmith scans every gem for known CVEs and malware, both on upload and on a continuous rescan basis as new vulnerability data becomes available. You can configure policy rules using Cloudsmith's OPA Rego-based policy engine to automatically quarantine, block, or send alerts for packages that exceed a defined severity threshold. This applies to privately published gems as well as gems fetched and cached from upstream sources like rubygems.org.

  6. Yes. Shopify - which runs one of the world's largest Ruby on Rails applications and is a major contributor to the Ruby core, Rails framework, and RubyGems toolchain - is a Cloudsmith customer. Shopify's engineering teams use Cloudsmith to manage artifacts across their software supply chain. If your team is building with Ruby at any scale, Cloudsmith gives you the security controls, audit trail, and performance that the public rubygems.org registry simply cannot provide.

  7. Yes. Cloudsmith Entitlement Tokens are designed exactly for this use case. You can create scoped tokens with configurable download limits, expiry dates, and IP restrictions, then share them with customers or partners without exposing your internal API key or user credentials. Tokens can be revoked instantly from the Cloudsmith UI, and all download activity is logged per token so you have full visibility over who is consuming your gems.

  8. Cloudsmith supports OIDC natively, meaning CI/CD platforms like GitHub Actions and CircleCI can authenticate to your Ruby repository without storing long-lived API tokens as secrets. Your CI provider issues a short-lived OIDC token, which Cloudsmith validates to grant access. This eliminates the risk of token leakage from CI secrets stores, removes the need for manual token rotation, and gives you more granular control over which workflows can push or pull from your gem repository.

  9. Yes. Cloudsmith repositories are multi-format by design. A single repository can store Ruby gems, Docker container images, npm packages, Maven artifacts, and over 30 other formats simultaneously. This means your team manages one platform, one set of access policies, and one audit log - rather than running a separate gem server, container registry, and Maven repo with separate authentication, permissions, and support overhead.

  10. Self-hosted gem servers like geminabox give you a private registry but require you to manage the infrastructure, keep it available, handle scaling, and build security controls yourself. Cloudsmith is fully managed: uptime, scaling, CDN delivery, CVE scanning, policy enforcement, audit logging, OIDC auth, and entitlement token management are all included. There is no server to patch, no disk to provision, and no on-call rotation for your artifact infrastructure.

Formats

There’s more than just Ruby Gems on Cloudsmith