Which strategy should I use for RubyGems Publish Workflow Changes?
Assess whether organization release workflows or account automation need changes after RubyGems.org terms and acceptable-use policies took effect on June 30, 2025.
Blockers
- requires_version: capability/key-management-flow → package/rubygems-3.2.0
- requires_version: capability/trusted-publishing → protocol/oidc
Who this is for
- compliance
- small-team
- enterprise
Candidates
Keep existing API-key publishing, but require a one-time account policy review and tighten key scope
As of 2026-04-03, RubyGems.org's new Terms of Service, Privacy Notice, Acceptable Use Policy, and Copyright Policy have already been in effect since June 30, 2025, and returning users are prompted to review and accept them when logging in. The Terms say that by registering for, using, or accessing the service, the user agrees to the Terms, and the Acceptable Use Policy now explicitly bans inauthentic activity, excessive automated bulk activity, and abuse of the package index. RubyGems still supports scoped API keys for publishing, yanking, and owner management, and keys can be limited to a single gem. RubyGems also recommends replacing migrated legacy keys with minimum-scope keys, and the guide says RubyGems 3.2.0 or newer is needed for the newer key-management flow.
When to choose
Use this when your current release automation already works and the main gap is governance, not tooling. It is the lowest-friction path if you can confirm that the human maintainers behind the publishing account have logged in, accepted the policies, and rotated any broad legacy credentials to gem-scoped minimum-privilege keys.
Tradeoffs
Least disruptive because it preserves existing CI steps and credentials. The downside is that long-lived API tokens remain a standing secret, and policy compliance depends on humans reviewing automation behavior and account state.
Cautions
Do not leave old all-scope or legacy-style keys in CI if the workflow only needs push access for one gem. If your automation performs bulk or non-package use of RubyGems.org, the Acceptable Use Policy now gives RubyGems explicit grounds to restrict or remove content or access.
Migrate CI publishing to RubyGems Trusted Publishing with OIDC
As of 2026-04-03, RubyGems documents Trusted Publishing as an official workflow that exchanges short-lived OIDC identity tokens for short-lived RubyGems publishing tokens, avoiding stored long-lived API credentials in CI. For GitHub Actions, RubyGems lets you register trusted publishers per gem, repository, workflow filename, and optional environment or reusable-workflow repository. The documented release workflow uses `rubygems/release-gem@v1` and requires GitHub Actions `id-token: write`, with `environment: release` when that environment is configured on RubyGems. This is a workflow change, not a new pricing tier in the cited RubyGems policy rollout materials.
When to choose
Use this when you want the cleanest post-policy security posture for organization-owned gems or shared CI systems. It is the better choice if you are rotating away from long-lived secrets anyway, or if multiple maintainers and reusable workflows make manual key handling risky.
Tradeoffs
Strongest security posture because CI no longer stores a reusable RubyGems secret. The tradeoff is setup work on both RubyGems.org and GitHub Actions, especially when using reusable workflows or protected environments.
Cautions
Your GitHub workflow must grant `id-token: write`, and RubyGems must be configured with the exact repository and workflow details it should trust. If you use reusable workflows, you may need the optional workflow-repository fields because RubyGems validates the actual workflow source reflected in the OIDC token.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Which strategy should I use for RubyGems Publish Workflow Changes?"