Skip to content

REFERENCE · 09

The tpkg-registry.yaml model.

A registry is any git-host repository carrying a tpkg-registry.yaml file — the git host's releases are the storage, with zero central infrastructure. The file mirrors only resolution-relevant fields, so the dispatcher can pick the right artifact for the operator's platform without downloading every payload.

The shape.

schema_version: 1
payloads:
  - name: hello
    kind: toolkit
    summary: "GNU hello — template prover payload"
    default: "2.12"
    versions:
      - version: "2.12"
        platforms:
          aarch64-macos:
            artifact: hello-2.12-aarch64-macos.tfs
            sha256: "0f1c7cc0…"
        release: {ref: tfs:github:tebako-packages/hello:2.12.1}

One entry per payload: the name and kind mirror the payload’s own manifest identity; default names the version a bare tebako install hello resolves; each version carries a platforms map with the per-triplet artifact filename and its SHA-256, plus the release reference the artifact is fetched from. A payload that ships one image for all platforms declares universal instead of the per-triplet map.

The file mirrors resolution fields only — the in-image manifest stays the authority for everything else, and unknown keys are tolerated for forward compatibility. tebako publish writes this file, and hand-editing is rare.

The four reference forms.

A registry reference names exactly one location — there is no fallback chain:

Form Resolves to

tfs:<service>:owner/repo

The tpkg-registry.yaml on the repository’s default branch.

tfs:<service>:owner/repo:version#tpkg-registry.yaml

The registry file as a release artifact.

tfs+git://host/owner/repo.git[@ref]#path

A git blob at the path.

file:///abs/path/tpkg-registry.yaml

A local mirror for tests, on-prem installs, and air-gapped fleets.

The walkthroughs are Publish to your own registry and Curate a local library.

See also: Manifest reference · Repositories · tebako CLI