UNDER THE LID
How the box works.
Beneath the poetry is solid engineering. Tebako combines a virtual filesystem, a patched Ruby runtime, and a single packaging command to produce portable executables.
The packaging pipeline.
A single command — tebako press — takes your application tree and produces a self-contained binary. Here is what happens inside.
Runtime execution flow.
When the user runs the executable, the tebako bootstrap orchestrates a carefully ordered sequence: mount the virtual filesystem, start the Ruby interpreter, then hand control to your application.
What's inside the executable.
The binary is not a simple wrapper — it is a nested stack of layers, each with a specific role. Understanding this structure explains why tebako binaries are self-contained yet compact.
Executable shell
The native binary format the OS loads. Contains the bootstrap code and embedded data.
Tebako bootstrap
Runs first on startup. Mounts the DwarFS image and patches Ruby's file path resolution so require finds gems inside the virtual filesystem.
Ruby runtime
A patched copy of the Ruby interpreter, embedded directly. No system Ruby needed.
DwarFS image
A high-compression read-only filesystem containing your entire app tree. Mounted at runtime.
Application code
Your Ruby files, gems, native extensions, and assets — everything your app needs to run.
PACKAGING MODES
Three ways to press.
Lean
Minimal package — just the application and its direct dependencies.
Fat
Includes the full Ruby runtime and all gems in a single self-contained binary.
Classic
The original packaging mode, bundling everything into one monolithic file.
The re-architecture
Tebako is undergoing a thrift-free re-architecture that removes folly and Thrift from the dependency stack — eliminating the build breakage that recurred across Ruby version bumps. The new engine uses a leaner libtfslayer on top of dwarfs-t, with prebuilt runtime packages for faster, more reliable builds.