Skip to main content
A repository is a named scope for commits and their tags. Where vers tag gives you a flat global namespace, vers repo lets you group related commits (e.g. a whole application) with tags scoped to that group (my-app:latest, my-app:v1.2). Repos can be public or private. Public repos can be forked by other organizations, which is how you share base images.

Synopsis

Subcommands

vers repo create

Naming rules: alphanumeric plus -, _, .; 1–64 characters. Unique within your organization.

vers repo list

List repositories in your organization.

vers repo get

Show details (owner, visibility, tag count, timestamps) for one repo.

vers repo delete

Delete one or more repositories. All tags in the repos are deleted too; the underlying commits are not touched.

vers repo fork

Fork a public repository into your organization. The fork:
  1. Materializes a VM from the source tag’s commit,
  2. Re-commits it under your org,
  3. Creates a new repo + tag pointing at that commit.

vers repo visibility

Toggle a repository between public and private.

vers repo tag

Tags scoped to a single repository. Same verbs as top-level vers tag, but qualified by --repo.

When to use repos vs plain tags

Plain tags

Flat, org-wide namespace. Best for a handful of long-lived names (production, staging) that don’t belong to any one application.

Repos + repo tags

Structured namespace. Best for versioned artifacts where the same tag name (latest, v1) is meaningful across many different things (my-api:latest, my-worker:latest).

Examples

Publish a base image

Other orgs can now consume it directly or fork it:

Multi-environment promotion

Common Patterns

Publish a base image and let others fork it

Promote a commit through environments

Fork and build on top

Bulk cleanup of test repos

See also

  • vers tag — flat, org-wide tags
  • vers build — produce the commits a repo holds
  • vers deploy — deploy from a GitHub repository (different concept: source code, not commits)