Documentation

From cloud registries

Hosted registries integrate with their platform's identity and billing. They charge for storage and egress, use expiring tokens, and may enforce pull-rate limits. peryx can host images or cache a cloud registry so each base layer crosses the upstream boundary once.

Cost and protocol differences

A self-hosted peryx instance has no per-GiB service charge and uses one configuration file. Its content-addressed blob store spans indexes, so one fetched base layer can serve multiple images. If platform IAM or compliance requires the cloud registry to remain the push target, use peryx as a cached index in front of it.

Configuration mapping

Point a peryx cached OCI index at the registry's /v2/ endpoint; its repository path becomes the index route prefix.

Registry/v2/ hostCached-index credentials
ECR{acct}.dkr.ecr.{region}.amazonaws.comusername = "AWS" and the 12-hour get-login-password token as password
GHCRghcr.iousername and a personal access token with read:packages as password
Google Artifact Registry{loc}-docker.pkg.devusername = "_json_key_base64" and the encoded service-account key as password
Azure ACR{registry}.azurecr.iousername and a token or service-principal secret as password

Constraints

  • ECR's short-lived tokens make it the one upstream peryx cannot front unattended today; a refresh-command hook is on the roadmap.
  • Cloud IAM does not translate: peryx reads are open to its network, pushes are token-gated per index.
  • Egress from the registry to peryx is still billed by the provider; the cache means you pay it once per layer.
On this page