tobi/onix — explained in plain English
Analysis updated 2026-07-21 · repo last pushed 2026-02-13
Import a Rails Gemfile.lock and share pre-built gems across all developers and CI via a shared cache.
Handle gems with native C extensions like Nokogiri by linking them to shared system libraries instead of bundled copies.
Create overlay files for gems needing special build steps such as Rust-based extensions.
Achieve identical gem builds on every machine without abandoning your existing Bundler lockfile workflow.
| tobi/onix | mitchellh/minitest-speed | patriciomacadden/icd | |
|---|---|---|---|
| Stars | 8 | 8 | 8 |
| Language | Ruby | Ruby | Ruby |
| Last pushed | 2026-02-13 | 2011-09-15 | 2015-12-02 |
| Maintenance | Maintained | Dormant | Dormant |
| Setup difficulty | hard | easy | easy |
| Complexity | 4/5 | 2/5 | 2/5 |
| Audience | developer | developer | developer |
Figures from each repo's GitHub metadata at analysis time.
Requires Nix installed plus Ruby 3.1 or newer, and you need a Gemfile.lock to start with.
Onix turns your Ruby project's dependency lockfile into reproducible, cacheable builds. Instead of relying on Bundler to assemble gems differently on every machine, you feed your existing lockfile in and get a set of packages that build identically everywhere, your laptop, CI, or a teammate's setup all share the same cache. The tool works in four steps. You run onix import to read a Gemfile.lock and convert it into a structured packageset file. Then onix generate fetches cryptographic hashes for every gem and writes out Nix build files, one per gem, plus one per project. onix build compiles everything in parallel. When a gem that needs system libraries fails, the tool tells you exactly which overlay file to create to fix it. Ruby gems with native C extensions (like Nokogiri or sqlite3) often bundle their own copies of libraries like OpenSSL or libxml2, which can cause version conflicts and security headaches. This project forces those gems to link against shared system libraries provided by Nix instead, replacing vendored copies. Each gem gets its own individually cacheable build, so if your lockfile and Nix setup stay the same, you never rebuild a gem twice. This is for Ruby teams already using or interested in Nix who want hermetic builds without abandoning Bundler's lockfile workflow. A Rails shop could import their Gemfile.lock, generate the build files once, and have every developer and CI pipeline pull pre-built gems from a shared cache. The overlay system lets you handle gems that need special treatment, like Rust-based extensions or gems with unusual build steps. The project makes a clear tradeoff: it requires Nix and at least Ruby 3.1, which adds setup overhead. But in return, you get builds that are fully reproducible and a caching model where "build once, cache forever" is literally true, same lockfile plus same nixpkgs equals identical store paths across machines.
Onix converts a Ruby Gemfile.lock into reproducible, cacheable Nix builds so every machine builds gems identically. Build once, cache forever, same lockfile and Nix setup means identical results everywhere.
Mainly Ruby. The stack also includes Ruby, Nix, Bundler.
Maintained — commit in last 6 months (last push 2026-02-13).
Setup difficulty is rated hard, with roughly 1h+ to a first successful run.
Mainly developer.
This repo across BitVibe Labs
Verify against the repo before relying on details.