GUIDES · 06

Publish to your own registry.

A tebako registry is a single YAML file, tpkg-registry.yaml, which consumers add once. The artifacts live on the publisher's own release pages, and no central server, no submission queue, and no other intermediary stand between the publisher and its users.

Note	This guide is part 5 of the Basic payloads tutorial. The blog chapter publishes a release from scratch.

The publish command.

The command takes one --payload option per platform triplet, each naming an image built by the publisher’s continuous integration (CI), and one release reference naming the destination.

$ tebako publish --name acme-tool --version 1.4.0 \
    --release tfs:github:acme/acme-tool:v1.4.0 \
    --payload macos-arm64=dist/acme-tool-1.4.0-macos-arm64.tfs \
    --payload linux-gnu-x86_64=dist/acme-tool-1.4.0-linux-gnu-x86_64.tfs \
    --payload linux-musl-x86_64=dist/acme-tool-1.4.0-linux-musl-x86_64.tfs

--payload <triplet>=<path> maps a platform to its built image, and the option is repeated once per platform. A single plain --payload <path> without a triplet publishes one universal artifact.
--standalone <triplet>=<path> additionally attaches a stitched single-executable build for that triplet — for users who never install tebako.
A live upload needs a token: TEBAKO_GITHUB_TOKEN (or GITHUB_TOKEN) with release write access.

publish uploads the payloads to the release, writes the registry index, and prints the result (representative):

published acme-tool 1.4.0 -> tfs:github:acme/acme-tool (tag v1.4.0)
sha256 9f2c…a1  acme-tool-1.4.0-macos-arm64.tfs
sha256 77b1…0e  acme-tool-1.4.0-linux-gnu-x86_64.tfs
sha256 c04d…63  acme-tool-1.4.0-linux-musl-x86_64.tfs
registry -> dist/tpkg-registry.yaml

Signing the artifacts.

--sign signs every artifact before upload: detached .asc signatures and a signed SHA256SUMS are published on the same release. Plain --sign uses the publisher’s press-local key (generated on first use), and --sign=<keyid> picks a specific key. The receiving end of signatures is covered in Verify integrity.

Rehearsal before upload.

$ tebako publish --name acme-tool --version 1.4.0 \
    --release tfs:github:acme/acme-tool:v1.4.0 \
    --payload macos-arm64=dist/acme-tool-1.4.0-macos-arm64.tfs \
    --upload-mirror ./mirror \
    --registry-out ./tpkg-registry.yaml

--upload-mirror <dir> writes the release tree to a local directory instead of uploading — exactly what would ship, inspectable offline. --registry-out <path> chooses where the index is written. By default publish verifies artifacts before upload, and --skip-verify turns that check off.

The Homebrew tap.

--tap <org/homebrew-tap> emits a Homebrew formula for the tool alongside the registry entry, and --tap-dir <dir> writes it into a local checkout of the tap. One publish run gives consumers two install routes.

The consumer side.

Two commands put the tool on a consumer’s PATH with version pins and upgrades:

$ tebako add-registry tfs:github:acme/acme-tool
$ tebako install acme-tool@1.4.0

Consumers who want the index itself pinned by hash add the registry with a sha256 parameter; the reference is quoted because it contains shell metacharacters:

$ tebako add-registry 'tfs:github:acme/acme-tool?sha256=9f2c…a1'

Other reference forms work as well: tfs:gitlab: and tfs:bb: for GitLab and Bitbucket, tfs+git:// for self-hosted indexes, and file:/// for local ones. Reading from GitLab and Bitbucket works today; publishing to them is not implemented yet, and the write leg fails with a named error.