The Tebako blog.

tebako v2.8.12: signed delivery end to end — installers, signatures, enterprise networks, and the completed windows platform

tebako v2.8.9: ruby 4.0 runtime lines, line-pinned extension slices, and the windows materialize tier

v2.8.9 has paired with the 0.16.25 runtime factory to make ruby 4.0 a first-class tebako target: one payload version can ship per interpreter line, the user picks the line with one pin, extension slices bind to the exact line they were built against, and windows runtimes whose files the OS loader must see gain the materialize boot tier.

tebako v2.8.2: doctor, the corporate-network trust bridge, offline bundles, and per-platform releases

v2.8.2 is the operability release: a doctor verb that diagnoses the store end to end, payloads that trust the corporate proxy's CA without a rebuild, offline bundles and signed system installers, and a release pipeline in which one broken platform no longer blocks the rest.

The trust chain is live: signed releases, signed payloads, zero-setup verification

The architecture series ended with trust as a concept; this week it became a feature set. Every tebako release asset has been OpenPGP-signed, the CLI carries the tamatebako root key, and a signed payload has verified on a fresh machine with zero key registration — demonstrated, not merely described.

CPython under the bench: the 3.14 interpreter is the win, and what the JIT (doesn't) buy you

The Python runtime line has received the same instruments as the Ruby line: CPython 3.13.15 and 3.14.7, plain and JIT-flavored, on synthetic kernels and on a real xml2rfc standards-document render, all through the real tebako dispatch path. The result mirrors Ruby's, with one difference: the 3.14 JIT flavor defaults on, and it still does not matter at the measured horizons.

Tebako runtimes under the bench: MRI vs TruffleRuby vs JRuby, and what the JITs actually buy you

The tebako project has measured five Ruby runtime arms through the real tebako dispatch path — MRI 3.3.12, MRI 4.0.6 with YJIT and ZJIT, TruffleRuby native and JVM, and JRuby on OpenJDK 25 — on synthetic kernels and on a real Metanorma document compile. The result is not a single fastest engine; the fastest engine depends on the shape of the process, and the packaging layer is where that choice belongs.

Tracing and checking packaged apps

Every packaged application raises two questions: what it actually touches on the machine, and whether it actually works. The trace commands answer the first question, payload checks answer the second, and this post presents both with worked examples.

Tebako v2 — the hermetic portable-runtime platform

Tebako v2 has shipped. To show what its portability means in practice, a complete standards document — figures, fonts, and the Java conversion pipeline included — has been built entirely from mounted disk images, with an empty PATH and nothing on the host but tebako itself.

Tebako is alive — the thrift-free re-architecture

The Tebako project is not dead: maintenance continues under the tamatebako organization, and the recurring build breakage has been addressed at its root by removing folly and Thrift from the stack entirely.

Understanding Tebako Packaging Scenarios for Ruby Applications

A comprehensive guide to the different packaging scenarios supported by Tebako

Setting the record straight: Tebako packaging capabilities

Thanks to Brad Gessler for his Tebako blog post! Here we clarify macOS Intel build capabilities and the intended gem release workflow to help developers implement Tebako more efficiently.

Tebako multi-architecture packaging containers now available on Docker

Tebako now offers Linux GNU and musl containers on amd64 and arm64 architectures with preinstalled Tebako environments.

Tebako announces support of packages based on Ruby 3.4 at v0.12.0

Tebako 0.12.0 now provides an option to create packages based on Ruby 3.4.1 on Ubuntu, Alpine, macOS and Windows.

Announcing Tebako v0.11.0: decoupling runtime and application

Tebako 0.11.0 separates runtime and application packaging for reusable Ruby execution, enhancing flexibility, efficiency, and simplified updates.

Tebako 0.9.0 enhances Ruby on Rails packaging with host folder mounting

Tebako 0.9.0 introduces the ability to mount host folders to memfs, providing seamless packaging support for Ruby on Rails applications. This feature helps overcome the challenge of dealing with Rails' hardcoded paths for temporary files, caches, and sockets.

Tebako 0.8.7 improves package portability on Linux distributions

Tebako 0.8.7 introduces forward compatibility for Linux distributions that depend on the GNU C Library (`glibc`).

Tebako announces support of packages based on Ruby 3.3 at v0.8.0

Tebako 0.8.0 now provides an option to create packages based on Ruby 3.3.3 and 3.3.4 on Ubuntu, Alpine, macOS and Windows.

Tebako announces full Windows support at v0.7.0

Tebako 0.7.0 now provides full support for Ruby on Windows 2019, Windows 2022.

Tebako Windows support at v0.6.0!

Tebako now officially supports Windows, including Windows 2019, Windows 2022 targets using MinGW ucrt64, at version 0.6.0 released today. Now Tebako supports packaging for most major platforms: Linux, macOS and Windows.

Details about Tebako patching processes

Building Ruby with minimal external dependencies is a challenging task loosely supported by the community. We faced numerous issues on this path and had to resolve them creatively.

Benchmarking of tebako package against original Ruby applications

A Tebako package created from a Ruby application introduces four features that can negatively affect performance. In this post we discuss performance comparison of Tebako package and original application and show that negative impact is minimal.

Using SSL in applications packaged with Aibika

Using SSL-powered features with Aibika may require additional handling of SLL certificates.

Introducing Aibika: Ruby executable packager on Windows built on Ocra

Aibika is a modernized version of the Ocra Ruby executable packager on Windows.

Tebako packager revisited

The distribution of Ruby applications can be considered an unsolved problem. By itself, Ruby does not provide a consistent and easy method for setting up and running a running application.

Tebako technology and data flow

The distribution of Ruby applications can be considered an unsolved problem. By itself, Ruby does not provide a consistent and easy method for setting up and running a complex application.

Challenges in distributing Ruby applications

The distribution of Ruby applications can be considered an unsolved problem. By itself, Ruby does not provide a consistent and easy method for setting up and running a complex application.