OCI compatibility

lazer.sh implements the OCI Distribution Specification v1.1. There is no lazer-specific registry API to learn, and we do not document one — any spec-compliant client works.

What follows is the honest support matrix.

Supported

Capability	Notes
`GET /v2/`	Version check and the auth challenge
Blob pull, `GET` and `HEAD`	Served from the edge
Chunked and monolithic blob upload	Uploads stream to storage rather than through the control plane
Manifest `PUT`, `GET`, `HEAD`, `DELETE`	By tag or by digest
Image indexes	Multi-architecture images and their children
Tag listing	`GET /v2/<name>/tags/list`, paginated
Blob delete	Subject to the `delete` scope
Token auth	Bearer tokens via `/token`, short-lived, scoped

Accepted media types cover OCI image manifests and indexes, and the Docker v2 schema 2 manifest and manifest list, so images built by older toolchains push without conversion.

Not supported

Capability	Status
Referrers API (`/v2/<name>/referrers/<digest>`)	Not implemented. Returns `UNSUPPORTED`. Attestations and SBOM attachment come with it
Cross-repository blob mount	Not implemented. Pushing the same layer into a second repository re-uploads it
Catalog (`/v2/_catalog`)	Not implemented. Listing every repository on a private registry is an information-disclosure risk we would rather not carry. Use the management API
Image signing	No Cosign or Notation verification enforced at the registry. Signatures push and pull as ordinary artifacts, but nothing checks them
Vulnerability scanning	Not offered. Scan in CI before you push

If one of these is blocking you, say so — the list reflects what has not been needed yet rather than a decision never to build it.

Rate limits

Registry reads, upload initiations, and manifest writes are rate limited per credential. The limits are set well above what an ordinary CI pipeline generates; if you hit one you will get a 429 with a Retry-After header, and a well-behaved client will back off on its own.