Publishing

Declare publication in crab.toml:

image = "connect/supabase"
template = true

crab publish builds source and publishes to the account and service named by image, without creating or changing a running instance. The context supplies the server and credentials; it does not replace that address. The version comes from Cargo.toml. Publication requires ownership of the target account; a key must be bound to that account and grant deployments:write. Direct publication uses --yes; other CLI publication requests use the usual approval flow.

crab deploy consumes the published release under your selected account. crab deploy --build deploys local changes without publishing them. An image address is optional for building and required for publication; a version suffix, when supplied during publication, must match Cargo's version.

Before publishing, measure and check each tool's budget on its built WebAssembly image. Publication without a running instance does not establish that the image can deploy within a host's ceilings.

Published images and retained versions count toward your account's storage allowance, even without a running instance. Uploads and publication are refused when they need more capacity than remains. Withdrawing a template keeps its retained versions and their storage.

crab publish [dir] selects the service in that directory or Cargo workspace services beneath it, including services marked deploy = false. The directory defaults to .. For example, crab publish services/connect from the repository root and crab publish inside services/connect select the same catalog. No catalog-level crab.toml is needed. Repeatable -p <name> selects services by name anywhere in the workspace instead.

public = true separately exposes your deployment. Both flags default to false. People deploying a template get a private instance with their own credentials and state; neither publication flag is inherited.

A template's documentation and deployment refer to the same image digest. Its public documentation contains image declarations, including internal tools and setup requirements, without runtime settings, credential values or usage. Documented internal tools remain unavailable through MCP and API calls.

Explore derives template credential requirements from the image's declared secrets and optional credentials, including linked dependencies. Public service pricing comes from its live deployment; template images do not set prices.

An optional logo = "https://example.com/logo.svg" in crab.toml supplies the logo shown on listings and service pages. The URL stays with the image and template copies; linked libraries do not contribute their logos. A missing or unavailable logo falls back to the existing service appearance.

Set template = false and publish again to withdraw a template. Existing copies continue working.

To delete a template and its retained release images, choose Delete template from the actions menu in its Template card or its account’s Templates list. Owners also see withdrawn templates in that list. Deletion requires a signed-in account owner. Version identities remain reserved. Running services and existing copies keep working. Unreferenced images are collected after outstanding upload URLs expire; images retained by deployment history remain stored. The API equivalent is DELETE /services/{owner}/{name}/template.

GET /users/{user}/templates?all=true and GET /orgs/{org}/templates?all=true include withdrawn templates for an authorized owner; API keys also require deployments:read. Without all=true, these endpoints return published templates only.

To classify your tools for discovery, assign catalog jobs in crab.toml. The Service catalog guide covers choosing jobs, writing a discoverable listing and proposing new platforms.

Releases

A published version identifies one image digest permanently. Publishing the same retained version and image again is idempotent; different content requires a new package version (E0041). Release notes are optional, at most 2000 characters:

crab publish services/connect/github --notes "Fix pagination for large repositories."

The template’s Versions tab shows release notes, publication dates and image availability. Select a retained version to read its documentation and deploy that exact image. Publishers can Yank or Unyank a release from its actions menu. Yanked releases remain visible but cannot create new copies or be selected for upgrades. New copies use the latest non-yanked stable release, or the latest non-yanked prerelease when no stable release is retained. Pinned copies stay on their image; opted-in copies can follow newer non-yanked patches through automatic updates.

Each template retains three release images. Publishing a fourth prunes the oldest image, keeping the default release and two other recent releases. Small version records remain after pruning or deletion so a version cannot be reused for different content. A pruned publisher image cannot create new template copies (E0040). Existing copies retain their own images under their own accounts.

Release images and the service’s current image plus two previous successful images share the account’s storage allowance. Pruned images are collected after upload URLs expire and no retained reference needs them; deletion does not immediately release capacity. New uploads still require available capacity. Withdrawing a template keeps its retained images but prevents new deployments.

The API exposes history at GET /services/{owner}/{name}/template/releases, exact selection at GET /services/{owner}/{name}/template?version=1.2.3, and yanking at PUT /services/{owner}/{name}/template/yank with {"version":"1.2.3","yanked":true} (false undoes a yank). Yanking requires an account owner and deployments:write for an API key.

Optional OCI registry

Images upload directly to the selected host by default. Configure a registry on the CLI context, or override it for one command:

crab context add local http://localhost:7777 --registry localhost:5001
crab --context local deploy --build
crab deploy --build --registry localhost:5001

The repository is <registry>/<owner>/<service> when image is declared, or <registry>/<Cargo package name> for a source-only deployment; its tag is the package version. Deployment pins the layer digest. A separate registry must be reachable from the CLI and node. Cloud accepts only its configured registry allowlist.

An OCI artifact contains the Wasm image as its one layer and the image manifest as its config blob. Registry availability does not grant CrabTalk template publication permission.

GITHUB_TOKEN supplies OCI registry credentials. ~/.docker/config.json is not read. BERM_REGISTRY_MIRRORS maps registry names to endpoints as comma-separated name=endpoint pairs. Loopback registries use HTTP.