Curate a local library.

Every tebako registry — GitHub releases, GitLab, a git repo, a local directory — is the same thing: a tpkg-registry.yaml index plus the artifacts it names. A file:// registry is the local form: the index sits in a directory on disk (or a Network File System (NFS) share, or a synced folder), and the artifacts sit next to it. There is no server process, no daemon, and no API — tebako reads the files.

That property makes it the on-prem / air-gapped pattern: one team curates the library, every machine adds it once, and installs resolve exactly as they would from a hosted registry.

The index mirrors only what resolution needs — name, kind, versions, entrypoints, and a file:// reference per artifact. For a universal payload the artifact’s SHA-256 is carried in the reference itself, as the ?sha256= pin:

The pin is the trust anchor: install verifies the downloaded bytes against it before anything lands in the store. (Per-triplet payloads put their pins in the platforms[<triplet>].sha256 map instead — see the registry schema.)

Each machine adds the library once and installs by name:

The registry index itself can be pinned as well; the reference is quoted because it contains shell metacharacters:

From there everything is the standard surface: shims dispatch acme-tool, TEBAKO_ACME_TOOL_VERSION=1.3.9 pins a version, and tebako cache list shows what is cached.

A file library is what makes TEBAKO_OFFLINE=1 a workable default instead of a restriction:

Offline means cache or named error — never a silent network attempt. Each machine’s store is seeded from the library (tebako install reads the file:// artifacts locally, verifies them against their pins, and caches them), and the offline mode is then turned on. Runs and dispatch touch only the store; anything missing fails with a named error naming exactly what is absent.

Publishing a new version is three steps, all local:

Consumers pick the new version up on their next tebako update-registries (the dispatch-time registry cache has a 24 h TTL; the refresh is the explicit verb). Installed versions keep working until they are pruned — updates never touch a machine that did not ask.

Stores grow; prune is safe because it never strands a pin:

The payload arm refuses to remove anything a pin can see: config defaults: pins (tebako shim use), exact payload@version disable selectors, and the newest installed version of every payload — the roll-forward floor — survive even --all. One caveat, printed by prune itself when it applies: .tebako-tools.yaml project pins are per-directory and invisible to prune, so a pinned-but-old version may be removed and will re-fetch from the library on next dispatch (offline: a named error).

file:// artifacts carry exactly the same verification as hosted ones: the registry’s SHA-256 pin is checked at install, the cached artifact keeps its .sha256 sidecar as the trust anchor, and runs never re-verify — which is what keeps them fast. Unsigned artifacts stay first-class but loud: a warning at install and a line in the audit journal. Fleets that want signatures enforced set TEBAKO_REQUIRE_SIGNED=1, and every unsigned install fails closed. The library directory itself is curated with ordinary filesystem permissions: whoever can write the index controls what the fleet installs.