Host packages on your own OCI registry.

Some deployments may not fetch from the public internet at run time: the network perimeter forbids it, policy requires that executable content pass through the organization’s own gates, or an audit requires that every installed byte be traceable to an artifact the organization itself served. These deployments already operate a registry for their container images, and the same registry can serve tebako artifacts, because a tebako payload or runtime is, on the wire, content-addressed bytes — the registry neither knows nor needs to know what the bytes contain.

One invariant makes the whole arrangement inexpensive: the bytes never change across transports. A payload mirrored from the public catalog into an organization’s registry is bit-identical with the public artifact, so its SHA-256 anchor is unchanged, its detached signature still verifies against the publisher’s published key, and the organization re-serves exactly what the publisher shipped rather than a rebuild it must now trust on its own authority. Mirroring is copying, and copying preserves the chain of custody.

A self-hosted arrangement serves three kinds of artifacts and one index:

On a machine that can reach both the public side and the organization’s registry, install the payloads once; the local store then holds byte-identical copies with their anchors, ready to be pushed onward.

Push each artifact to the organization’s registry under the tag grammar the index will reference — one repository per payload, one tag per (version, triplet) pair, and one sha256-<hex>.asc tag per signature, which is the form that lets a consumer fetch a signature without knowing anything but the artifact’s hash:

Any OCI client performs the push, because the artifacts are ordinary registry blobs; tebako’s own publishing machinery emits the same grammar when a feedstock publishes with an OCI destination, so an organization that packages its own software with tebako publishes to its registry directly and skips the mirroring leg for those payloads. The push must preserve bytes exactly — a registry or proxy that recompresses or rewrites blobs breaks the anchor, and the verification steps below will say so by name.

The index is one YAML file. Each row mirrors the public row’s shape, with the oci: locator naming the organization’s registry and the hash and signature fields carried over unchanged:

The organization’s private payloads take rows of the same form in the same index. A private flavor that extends a public base declares its dependency on the base by exact version — the loader mounts the base and the flavor together from the organization’s registry, and the base’s row never needs to know that the flavor exists.

Consumers register the index once, in ~/.tebako/config.yaml:

Keeping the public registry in the list makes the organization’s index an overlay — its rows win for the names it carries, and everything else resolves publicly. Removing the public entry pins resolution to the organization’s index alone, which is the correct posture for a fleet that must install only what the organization serves. TEBAKO_OFFLINE=1 goes one step further and turns every run into cache-or-named-error, which suits sealed networks after the initial seeding.

The OCI transport reads the docker credential store, so an operator who has run docker login registry.corp.example needs no further configuration — the existing habit works unchanged. For continuous integration (CI) runners and other headless machines, credentials live in config.yaml in environment-indirected form, so the secret itself comes from the runner’s secret store and never sits on disk:

Credentials are confined to the host they belong to: a token for the organization’s registry is never sent to any other host, and a payload’s origin is recorded at install so that later resolution does not silently cross registry boundaries.

Two enterprise realities are covered by the sibling guide and named here for completeness. A registry served under an internal certificate authority is trusted by adding that authority to tebako’s certificate store, and an egress proxy between the fleet and the registry is declared in the same configuration file; Enterprise networks gives both halves.

An organization that publishes its own payloads signs them with its own key in its own CI, and its registry rows declare the signer’s fingerprint. TEBAKO_REQUIRE_SIGNED=1 then fails closed on anything unsigned — including, deliberately, the organization’s own artifacts until they are signed — and Verify integrity covers the verification surface in full.

The OCI transport for payloads is available today, and the public catalog exercises it: the metanorma and xml2rfc payloads serve per-triplet tags and signature digest-tags from the project’s own container registry, anonymously. The OCI transport for runtimes — oci: locators on runtime rows, so that the interpreter pair also resolves from an organization’s registry — is the arriving extension of the same lane; until it lands, a self-hosted deployment seeds runtimes into the machine-wide cache through its installer or image pipeline, which is an out-of-band step that needs no registry support. A deployment with no registry at all is served by the file:// library or by stitched single-executable installers, which carry the runtime inside the package and need no network of any kind.