Service endpoints

Almost every path the Virtual Registry receives belongs to a package and is routed to a remote. A few are answered by the Virtual Registry itself, on every listener and whatever Host the request carries, so a package whose path collides with one of them cannot be served.

Health and readiness

/healthz and /readyz both answer 200 with an empty body, and are equivalent. They are answered inside Varnish, before any routing, so a 200 means the process is up and serving with a loaded VCL. It says nothing about whether a remote registry is reachable, and a probe against a Virtual Registry whose every remote is down still passes.

curl -I http://127.0.0.1/healthz
HTTP/1.1 200 OK

Health of the remotes is a separate matter, configured per remote with a probe.

Rewritten fetches

A manifest often points at a host other than the registry that served it: an object store holding an npm tarball, a signed download URL from Artifactory, a Git LFS object. Left alone, those URLs would take the client straight to that host and past the cache.

The Virtual Registry rewrites them to point back at itself, in the form /redirectz/<scheme>/<host>/<path>, so the fetch runs through the cache like any other. Clients never construct these URLs, they follow them out of a manifest or a redirect. What the endpoint accepts is controlled by redirects, including HMAC signing and restricting which upstream hosts it will fetch from.

ACME challenges

When acme.domains is configured, requests under /.well-known/acme-challenge/ are routed to the challenge server on acme.port, which listens on loopback. The certificate authority reaches the challenge on port 80 like any other request, and nothing else needs to bind it.

Metrics

The Prometheus scrape endpoint is not served on the Varnish listener. With otel.metrics.exporter: prometheus it is a listener of its own, /metrics on prometheus_host and prometheus_port, which defaults to loopback on port 9464.