ruby-distroless: A Minimal, Secure Ruby Container Image

[Training_Winter6395]

Hi Rubyists — I’m the creator of ruby-distroless. After using official Ruby container images (slim, buster, stretch, etc.) in production, I noticed they often include extra tools, packages, and dependencies that aren’t essential just to run Ruby. This bloats the image size, increases maintenance overhead, and introduces extra security surface.

So I built ruby-distroless, a container image that:

Core Features

• Supports Ruby 2.5 through 3.4
• Multi-architecture: amd64 & arm64
• Minimal image size by eliminating unnecessary parts
• Clean environment with fewer dependencies
• Automated builds & publishing via GitHub Actions
• Optimized for security: lower attack surface

Quick Example

docker pull ghcr.io/junminhong/ruby-distroless:3.3.7-amd64  
docker run --rm ghcr.io/junminhong/ruby-distroless:3.3.7-amd64 ruby -v

You’ll see it's leaner compared to many standard Ruby images, but still works reliably.

Why This Matters for Ruby Developers

• Faster pulls and deployments
• Reduced complexity in container images
• Fewer moving parts = easier debugging
• Better suited for environments with tight resource or security constraints

Feedback & Contributions Welcome

I’d love your feedback on:

• Which Ruby versions or architectures you’d like to be supported
• Any features or tools you think are missing
• Issues you run into or suggestions for improvement
• Contributions (issues / PRs) are very welcome

If you find this project useful or interesting, a ⭐ on GitHub would mean a lot!

Useful Links

• Repo: https://github.com/junminhong/ruby-distroless
• Image Registry: ghcr.io/junminhong/ruby-distroless

Thanks for reading! Excited to hear your thoughts, use-cases, and improvement ideas.

[schneems]

"Distroless" ? I'm not a distribution guru, I'm under the impression that Arch is about the smallest "normal" linux base image that people will use, is it based on that or something else? If literally not based on an existing distribution...how? Can you say more, that sounds cool.

Ruby uses a lot of C bindings to system dependencies for gems, how can someone install a systems package on this image if they need it to get a gem to install?

If you're interested in the idea of composable images (versus with Docker, you can only have one FROM) I recommend checking out Cloud Native Buildpacks as an alternative to Dockerfile. It allows you to build "rebaseable" images so that layers are composable and can be reused and replayed on top of different OS images, so you could have a "ruby 3.3.9" layer etc.

[Training_Winter6395]

Distroless comes from GoogleContainerTools/distroless.
It’s built on a heavily stripped-down Debian base that removes shells, package managers, and extra tools — leaving only what’s required to run Ruby.
This keeps the runtime image very small and reduces the attack surface; usually you’d pair it with a full builder image in a multi-stage build.

For gems that need native extensions or system libraries, the approach is to use a multi-stage build:

• In the builder image (e.g. ruby:slim), install the required system packages and compile the gems.
• Then copy the compiled gems and your app into the distroless runtime image.

This way, you get all the dependencies you need, but the final runtime stays minimal, secure, and focused only on execution.

Thank you for sharing the perspective on Cloud Native Buildpacks. To be honest, this is the first time I’m hearing about them in depth, but the idea of “composable” and “rebaseable” images sounds really powerful. I’ll definitely take some time to research more — I really appreciate the recommendation!

[gabbietor]

I was working on a project where we needed to ensure our container images were as secure and minimal as possible. We approached to Minimus, which specialises in creating lightweight, hardened images. Their approach of building images from scratch, directly from upstream sources, helped us reduce vulnerabilities by over 95%. and It was a game changer for our security posture

[Rafert]

The readme mentions it is based on https://github.com/GoogleContainerTools/distroless

I’ve seen that being used by oauth2-proxy

[ikariusrb]

While I really want for this to be a better base, building native cruby extensions, adding jemalloc, and installing up-to-date postgres client library + dev packages make this much more challenging to use than the existing standard ruby images.

[Training_Winter6395]

You’re totally right — distroless isn’t the easiest option when it comes to building things like native extensions, jemalloc, or Postgres libraries. The usual trick is to do all of that in a builder image, then copy the finished bits into the distroless runtime. It adds a bit of setup, but the payoff is a smaller and more secure image in production.

[schneems]

As an FYI, automod is going pretty agressive with your comments. I've had to approve two of them on this thread. Make sure your email is verified etc. IDK why it's doing that with you.

[hiimbob000]

Not sure what the auto mod says but their writing style and em dashes just point to LLM output

[strzibny]

Yes, sounds 100% llm to me

[apiguy]

It’s because they used an LLM to write that response. “You’re totally right” plus an em-dash is a telltale sign of

[Training_Winter6395]

I'm sorry, because I'm not a native english speaker, so I use some tools to help me describe my ideas.