WHO IT'S FOR

Built for people who ship software.

Tebako packages an application and everything it needs into one file that runs anywhere — with the isolation and portability of a container, and the weight of a file you can email. Here is who that helps, and why.

開

DEVELOPERS

Ship the app, not the runtime conversation.

Press once, and your users run it. Your README stops saying "install Ruby first" — the runtime downloads itself on first run, or rides inside the package.
One file per platform, or a registry payload with shims and version pins. Your entry points become ordinary commands on your users' PATH.
Native extensions are not a caveat. Compiled gems, FFI libraries, and platform-specific code mount and run inside the package.

組

ORGANIZATIONS

One artifact per platform, on your own infrastructure.

Self-hosted by construction: a registry is a YAML index plus your own GitHub releases. No store to operate, no third party between you and your users.
Signed slices, verified at install time with keys you control. Run workloads you do not fully trust inside jails — the filesystem view is read-only unless you grant more.
No daemon, no root, no background service. The artifact is a file; the runtime is a directory; the audit journal is a log line per event.

放

OPEN-SOURCE PROJECTS

Your releases are the store.

Publish from your own repository's releases page — there is no submission queue, no review gate, no namespace to defend.
Your users run two commands: tebako add-registry you, then tebako install your-app. They get a PATH shim, version pins, and upgrades for free.
Your identity stays yours: artifacts are signed with your key and pinned by your users on first contact, with out-of-band confirmation.

THE FOUR AUDIENCES, EXACTLY

Who compiles what: nobody you know.

The platform has one rule about compilation: prebuilt artifacts flow downward, compilation never flows outward. That rule partitions the world into four audiences — and decides what each one needs on their machine.

A · THE USER WHO RUNS A PACKAGED TOOL

Needs: nothing.

An editor at a standards body gets a new MacBook on Monday. She installs tebako from the brew tap — or downloads her organization's packaged tool directly — and runs metanorma compile report.adoc. The first run downloads the ruby runtime once, verifies it, caches it. There is no Xcode, no Ruby, no Java, no Inkscape, no "now install the dependencies" — and no tebako conversation either: the tool is on her PATH and behaves like any other command.

B · THE DEVELOPER SHIPPING A DATA-ONLY PAYLOAD

Needs: the tebako CLI. No toolchain.

A foundry ships versioned font collections; a research group ships a dataset with a release line. They point the prebuilt tfs mkimage at a directory, add a manifest, and publish the image on their own GitHub releases. Imaging runs in-process inside the CLI — there is no compiler to install because there is nothing to compile. Consumers mount the payload read-only; one copy on disk serves every application that needs it.

C · THE DEVELOPER SHIPPING A RUNNABLE PAYLOAD

Needs: to compile their own code. Only their own code.

The Metanorma team ships a Ruby application with 260 gems, some with native extensions. The gems they compile are theirs — tebako itself arrives as binaries: the bootstrap is a published artifact under 3 MB, the runtimes come from the runtime factory, the packager is a static binary. Their CI presses one payload per platform (or one universal payload for pure-ruby code), signs it, and publishes it to their own releases page. Their users never learn what a gem is.

D · THE TEBAKO STACK DEVELOPER

Needs: the full toolchain.

The people building tebako itself — the Rust product, the ruby patch factory, the runtime factory, the compression library — are the only audience that compiles the stack. Their output is the prebuilt artifacts everyone above consumes. If you are reading this to decide whether you need a compiler: you are almost certainly audience A, B, or C, and the answer is no.

THE FLAGSHIP, END TO END

Metanorma: four publishers, one compile, empty PATH.

Metanorma is the standards-authoring toolchain behind ISO, IEC, and a dozen other bodies — and the hardest packaging case we could find: a 260-gem Ruby application that shells out to a JVM for validation and PDF rendering, and to Inkscape to rasterize figures. In v2 it is a composition of four independently published, independently versioned slices, resolved and co-mounted per run. This is the closure, exactly as it ships:

The user installs two things — the tebako CLI and the metanorma payload — and types one command. The dispatcher reads the app's manifest, finds the cached compatible ruby (or downloads it once), mounts Inkscape and the JRE at the paths the app declared, and the compile runs. A Temurin security update ships as a new openjdk slice: existing installs pick it up by constraint, and no metanorma artifact is rebuilt, re-downloaded, or re-verified.

The proof point, run as an end-to-end test: PATH= metanorma compile site.adoc on an ordinary machine produced a valid PDF 1.7 — figure rasterized by the in-image Inkscape, validation and rendering by the in-image JVM — byte-for-byte the size of the host-built original. Nothing on the host participated, so nothing on the host can break it.

THE POSITION

A container's promises, at a file's weight.

Containers made three promises: run anywhere, carry everything, stay isolated. Tebako keeps all three for applications — without the daemon, the layered tarballs, or the registry infrastructure they normally ride on.

	Container	Static binary	Tebako
Runs on a clean machine	with a daemon installed	yes	yes
Shares the common parts	layers, server-side	no — every binary carries its world	yes — one runtime per machine, shared
Isolation	kernel namespaces	none	user-space jails: mount views, read-only by default
Distribution	registry infrastructure	any file host	any file host, plus a small YAML index
Background services	a daemon, often root	none	none
Trust	optional signing tooling	OS code-signing only	per-slice signatures with pinned publisher keys

HONEST BOUNDARIES

What it is not.

Not a security sandbox for hostile code. Jails control what a payload can see and write on the filesystem — they do not meter CPU, memory, or network.
Not server orchestration. Tebako distributes command-line tools, developer tooling, and desktop applications. It does not schedule services across a fleet.
Not a central store. There is no tebako-run repository of record, and there never will be. Registries are files you host; trust is pinned by the user, not granted by a platform.

Try it on your machine.

One install, no daemon, nothing running in the background.

Homebrew (macOS, Linux)

brew install tamatebako/tap/tebako

Shell (any Unix)

curl -fsSL https://tebako.org/install.sh | sh

Then: tebako add-registry tfs:github:tamatebako/hello andtebako install hello — a first packaged command in about a minute. The architecture documentation explains what just happened.