ARCHITECTURE · COMPARISONS
Compared, honestly.
"Package once, run anywhere" has been promised before — usually with an asterisk: a compatible JVM already installed, an engine already running, a machine that looks like the build machine. Here is where tebako actually sits among the tools you know, including where they win.
What a process sees, in each world.
Strip away the packaging formats and the difference is one question: when your program calls open(), what answers?
The landscape, in one table.
No column is all green, including ours. Read the rows you care about.
| Tebako | Docker/OCI | rbenv/rvm | Homebrew | RubyGems | Installers | snap/flatpak | VMs | |
|---|---|---|---|---|---|---|---|---|
| Unit of distribution | one file: app + verifier + runtime reference | layered image tarballs | nothing — it manages installs | a bottle (tarball) per formula | a .gem per library | .dmg / .pkg / .msi per app | a snap via the store | a disk image (GBs) |
| Runtime sharing | yes — one verified copy per machine, all apps share it | layers, server-side only | yes, per ruby — apps not isolated | shared, but floats with the repo | shared per ruby install | no — every app carries its world | shared runtimes exist, store-mediated | no — a whole OS per workload |
| Install footprint | ~/.tebako + one PATH entry | an engine, usually root; a VM on macOS/Windows | shims + ruby builds | /opt/homebrew, root-adjacent | the ruby installation | system-wide, admin rights | a daemon + system mounts | hypervisor + guest OS |
| Reproducibility | a closed function of bytes — the same artifacts the publisher tested | reproducible inside a Linux ABI only | no — rebuilds drift | no — installs float with repo state | no — resolution floats | whatever the installer bundled | channels float; confinement varies with the host kernel | yes, at enormous weight |
| Isolation | declarative per-run filesystem jails — no root, no daemon | kernel namespaces | none | none | none | none | kernel confinement, distro-dependent | hardware boundary — the real thing |
| Trust | the object: SHA-256 anchors + opt-in OpenPGP, verified offline | the channel + optional signing tooling | the channel | the channel | the channel; signing rare in practice | OS code-signing: "may this binary run?" | the store | whatever you put inside |
| Offline / air-gap | full, once the cache is warm — TEBAKO_OFFLINE=1 | pull first, and the engine must run | after install | no | after install | yes | no | yes |
| Version management | per-invocation dispatch: env → project pin → user default → registry default | tags, by hand | the whole point — per-shell | one version per formula name | gemsets / bundler | no | channels | no |
Where each alternative genuinely wins.
Tebako is a distribution format for applications, not a bid to replace your package manager, your container engine, or your hypervisor.
| RubyGems | sharing code between developers. Tebako packages applications; gems remain how developers share libraries. |
| rbenv / rvm | hacking on ruby itself. If your job is building interpreters, you want a version manager, not a package. |
| Homebrew / apt / dnf | OS-integrated components with a security-update channel. Tebako deliberately never manages the OS. |
| Installers (.dmg/.msi) | deep OS integration: drivers, system extensions, things that must be on the host. |
| snap / flatpak | store discoverability and automatic updates — a real distribution channel, with a daemon attached. |
| Docker / OCI | server-side multi-process orchestration. Tebako distributes tools to people; Docker runs services on fleets. |
| Virtual machines | hard boundaries for hostile native code. Jails are filesystem policy, not a hardware security boundary. |
What exists nowhere else.
- A single file that is simultaneously the app, its verifier, and its runtime resolver — self-authenticating, offline, over any transport including a USB stick.
- Universal payloads over digest-pinned shared runtimes — a pure-language app ships one image for every platform, and the runtime underneath it downloads once per machine. The fidelity of bundling, the footprint of sharing.
- Recursive payload composition — an app declares toolkits and data at mount points, each independently published and versioned, resolved from a provides/requires graph.
- Per-run declarative jails for the end user — no daemon, no root, no kernel module; tighten any command's filesystem view at invocation time.
- One signed-image algebra at every level — sources, runtimes, payloads, packages, registries — verified the same way, with verification that survives redistribution through untrusted mirrors.