Registry
Every Vetrix repository carries package registries alongside its code: a
built-in OCI container registry plus npm, PyPI, Go module, and generic artifact
endpoints. These pages are client-facing — the URL to point tooling at, how to
present a credential, and which endpoints each protocol serves. The whole
registry surface is mounted only when the operator has wired an on-disk blob
root, so a 404 on /v2/ means the deployment has no registry rather than no
image.
Per-ecosystem endpoints
- Container registry — The OCI Distribution Spec v1.1
/v2/API behinddocker login,push, andpull, and how an image name maps onto{owner}/{repo}[/{image}]. - Generic artifact registry — Arbitrary binaries uploaded by
curlunder{name}/{version}/{filename}and stored by SHA-256 digest, so re-uploading identical content is a no-op. - Go module proxy — The GOPROXY-compatible proxy selected through the
GOPROXYvariable and authenticated from.netrc, serving the@v/list,.info,.mod, and.zipmodule paths. - npm registry — The per-repository npm registry, pointed at by an
_authTokenline in.npmrc, serving packument reads, tarball downloads, andnpm publish. - PyPI registry — Publishing with
twinefrom a.pypircentry and installing from the PEP 503 simple index with pip or Poetry, including the dependency-confusion warning about--extra-index-url.
Across every registry
- Authorization and telemetry reference — The
per-route table of required permissions and 401/403/404 responses for all five
protocols, plus the
registry.*analytics events emitted on push and pull. vetrix/publish-artifactaction — The bundled CI action that builds an image and pushes it without handling credentials, with its input and output tables and the defaultsha-<7char>,branch-<slug>tags.