Documentation

From cloud registries

Hosted registries integrate package access with their cloud or development platform. peryx can replace their Python repositories or cache an existing repository when platform identity, policy, or ownership must remain there.

For upstream credentials, follow the provider's current setup for GitLab tokens, Azure Artifacts, or Google Artifact Registry.

Peryx differences

Peryx serves PEP 658, PEP 691, and PEP 700 from each PyPI index. When the cloud registry must remain the upload target, configure it as a private cached index. Peryx keeps the downstream route and cache local; the cloud registry keeps package ownership and upstream authorization.

Configuration mapping

RegistryIts simple URLAs a peryx cached index
CodeArtifacthttps://{domain}-{acct}.d.codeartifact.{region}.amazonaws.com/pypi/{repo}/simple/credential_exec returning a fresh Basic or bearer token
GitLabhttps://host/api/v4/projects/{id}/packages/pypi/simpleusername and password for a personal, deploy, or job token
Azure Artifactshttps://pkgs.dev.azure.com/{org}/{proj}/_packaging/{feed}/pypi/simple/username and password for a PAT
Google ARhttps://{loc}-python.pkg.dev/{proj}/{repo}/simple/credential_exec or documented Basic authentication

Pitfalls

  • Configure credential_exec for expiring upstream credentials. Its response includes the expiry, so peryx refreshes the credential before the next upstream request.
  • Cloud IAM does not authorize Peryx's downstream routes. Configure anonymous or protected reads and scoped client tokens separately.
  • A peryx cache changes client traffic, not provider billing rules. Check the provider's current storage, request, and data-transfer prices before keeping the registry as an upstream.
On this page