jruby

packaged by Chainguard

Chainguard Container for jruby

Minimal JRuby base image. JRuby is an implementation of Ruby on the JVM, available on Adoptium OpenJDK 21 and 25 in both JDK and JRE variants.

Chainguard Containers are regularly-updated, secure-by-default container images.

Download this Container Image

For those with access, this container image is available on cgr.dev:

docker pull cgr.dev/ORGANIZATION/jruby:latest

Be sure to replace the ORGANIZATION placeholder with the name used for your organization's private repository within the Chainguard Registry.

Variants

JRuby runs on a JVM, so every tag pairs a JRuby release with an Adoptium OpenJDK version and with either a full JDK or a JRE, mirroring the tag scheme the official JRuby image on Docker Hub publishes from jruby/docker-jruby. Tags are suffixed -jreNN or -jdkNN; unsuffixed tags, including latest, are the JRE on the default OpenJDK version. See the Containers Directory for the tags available today.

Use a jre tag to run applications, and a jdk tag when the same image also needs Java build tooling such as javac or jshell.

Each tag has a matching -dev variant that adds a shell, a package manager and build-base, for use as the build stage of a multi-stage build.

Compatibility Notes

These images are comparable to the official JRuby image on Docker Hub, but there are differences you should be aware of before migrating:

• net-telnet and xmlrpc are not preinstalled. The upstream image runs gem install net-telnet xmlrpc during its build. These images ship only JRuby itself; install those gems yourself if you need them. Note this also means webrick is absent — upstream gets it as a dependency of xmlrpc, not from JRuby.
• The images do not run as the root user and contain only the minimum packages they need to operate.
• USE_SYSTEM_CA_CERTS and the /certificates drop-in are not supported. Upstream inherits a /__cacert_entrypoint.sh wrapper from eclipse-temurin that rebuilds the JVM keystore at container start. These images instead symlink the JVM keystore to a package-managed store, so the OS trust store is already honoured with no startup work. To add a custom CA, rebuild /etc/ssl/certs/java/cacerts or set -Djavax.net.ssl.trustStore.
• JRuby prints Warning: AppCDS archive directory is not writable, disabling AppCDS operations on startup. The JRuby launcher wants to cache a JVM class-data-sharing archive inside its own installation directory, which is read-only for the non-root default user. JRuby runs normally without it; pass --nocache, or set JRUBY_JSA to a writable path, to opt out or to relocate the archive.
• JRuby applications typically install third-party dependencies through RubyGems or Bundler. The production images do not include a package manager, so use a multi-stage build that installs gems in a -dev variant and copies the result into the minimal image.

Getting Started

Evaluate a one-liner:

docker run --rm cgr.dev/ORGANIZATION/jruby jruby -e 'puts "hello from #{RUBY_ENGINE} #{RUBY_VERSION}"'

Start an interactive JRuby REPL (the default command):

docker run --rm -it cgr.dev/ORGANIZATION/jruby

Run a script from the working directory:

docker run --rm -v "$PWD:/work" cgr.dev/ORGANIZATION/jruby jruby app.rb

Use the image as the base for a Ruby application:

FROM cgr.dev/ORGANIZATION/jruby:latest-dev AS build
WORKDIR /work
COPY Gemfile Gemfile.lock ./
RUN bundle install

FROM cgr.dev/ORGANIZATION/jruby:latest
WORKDIR /work
COPY --from=build /usr/local/bundle /usr/local/bundle
COPY . .
CMD ["-S", "rake"]

Configuration

The images set the following environment variables:

PATH includes /usr/local/bundle/bin, so binaries provided by installed gems are directly executable.

The working directory is /work, which is world-writable.

What are Chainguard Containers?

Chainguard's free tier of Starter container images are built with Wolfi, our minimal Linux undistro.

All other Chainguard Containers are built with Chainguard OS, Chainguard's minimal Linux operating system designed to produce container images that meet the requirements of a more secure software supply chain.

The main features of Chainguard Containers include:

• Minimal design, without unnecessary software bloat
• Daily builds to ensure container images are up-to-date with available security patches
• High quality build-time SBOMs attesting to the provenance of all artifacts within the image
• Verifiable signatures provided by Sigstore
• Reproducible builds with Cosign and apko (read more about reproducibility)

For cases where you need container images with shells and package managers to build or debug, most Chainguard Containers come paired with a development, or -dev, variant.

In all other cases, including Chainguard Containers tagged as :latest or with a specific version number, the container images include only an open-source application and its runtime dependencies. These minimal container images typically do not contain a shell or package manager.

Although the -dev container image variants have similar security features as their more minimal versions, they include additional software that is typically not necessary in production environments. We recommend using multi-stage builds to copy artifacts from the -dev variant into a more minimal production image.

Need additional packages?

To improve security, Chainguard Containers include only essential dependencies. Need more packages? Chainguard customers can use Custom Assembly to add packages, either through the Console, chainctl, or API.

To use Custom Assembly in the Chainguard Console: navigate to the image you'd like to customize in your Organization's list of images, and click on the Customize image button at the top of the page.

Learn More

Refer to our Chainguard Containers documentation on Chainguard Academy. Chainguard also offers VMs and Libraries — contact us for access.

Trademarks

This software listing is packaged by Chainguard. The trademarks set forth in this offering are owned by their respective companies, and use of them does not imply any affiliation, sponsorship, or endorsement by such companies.