Is your feature request related to a problem? Please describe.
APM currently resolves dependencies primarily through Git-based references. While this works well for repository-based packages, enterprise teams also need a first-class way to distribute private packages through existing artifact infrastructure, authenticate registry access, verify downloaded artifacts, and integrate with standard package governance workflows.
Teams should also be able to use semver-based version selection when it fits their release process, without forcing all registry-published package versions to be semver. Many organizations already use Git-flow style selectors such as main, stable, v1.0.0, promotion labels, or commit-like pins, and registry support should not block those flows.
Describe the solution you'd like
Add a package registry resolver alongside the existing Git resolver.
The feature should allow users to declare registries in apm.yml:
registries:
corp-registry:
url: https://registry.example.com/api/apm/
default: corp-registry
dependencies:
apm:
- acme/foo#^1.2.3
- acme/bar@corp-registry#main
- registry: corp-registry
id: acme/prompt-pack
path: prompts/review.prompt.md
version: 1.4.0
Registry-routed dependencies should require an explicit version/ref selector, but that selector should not be required to be semver to be consistent with current git based flows.
If the selector is a semver version or range, APM should use semver matching and pick the best matching published version.
If the selector is not semver, APM should match it exactly against the versions advertised by the registry.
The registry resolver should support authenticated downloads via environment variables, sha256 verification, source-aware lockfile entries, and should avoid probing GitHub for registry-sourced dependencies. Existing Git dependency behavior should remain unchanged unless the experimental flag and registries: block are used.
Describe alternatives you've considered
Continuing to use Git refs for all dependencies is possible, but it does not provide a clean registry abstraction, artifact-level integrity metadata, registry-specific authentication, or enterprise-friendly package governance workflows.
Another option would be to rely only on marketplace search, but that does not solve install-time resolution from private registries. A publish CLI could also be added, but that can be deferred while operators upload packages directly to the registry API.
Additional context
This feature is intended to support enterprise and self-hosted package distribution without changing the default Git-based dependency flow. Registry support should be additive and opt-in while the API stabilizes, which is why it is proposed behind an experimental flag.
A registry-backed flow gives organizations a path to use existing artifact management, access control, audit, retention, and promotion workflows for APM packages. The initial scope can focus on install-time resolution and documented HTTP API compatibility; publishing and package lifecycle management can remain future extensions.
Is your feature request related to a problem? Please describe.
APM currently resolves dependencies primarily through Git-based references. While this works well for repository-based packages, enterprise teams also need a first-class way to distribute private packages through existing artifact infrastructure, authenticate registry access, verify downloaded artifacts, and integrate with standard package governance workflows.
Teams should also be able to use semver-based version selection when it fits their release process, without forcing all registry-published package versions to be semver. Many organizations already use Git-flow style selectors such as main, stable, v1.0.0, promotion labels, or commit-like pins, and registry support should not block those flows.
Describe the solution you'd like
Add a package registry resolver alongside the existing Git resolver.
The feature should allow users to declare registries in apm.yml:
Registry-routed dependencies should require an explicit version/ref selector, but that selector should not be required to be semver to be consistent with current git based flows.
If the selector is a semver version or range, APM should use semver matching and pick the best matching published version.
If the selector is not semver, APM should match it exactly against the versions advertised by the registry.
The registry resolver should support authenticated downloads via environment variables, sha256 verification, source-aware lockfile entries, and should avoid probing GitHub for registry-sourced dependencies. Existing Git dependency behavior should remain unchanged unless the experimental flag and registries: block are used.
Describe alternatives you've considered
Continuing to use Git refs for all dependencies is possible, but it does not provide a clean registry abstraction, artifact-level integrity metadata, registry-specific authentication, or enterprise-friendly package governance workflows.
Another option would be to rely only on marketplace search, but that does not solve install-time resolution from private registries. A publish CLI could also be added, but that can be deferred while operators upload packages directly to the registry API.
Additional context
This feature is intended to support enterprise and self-hosted package distribution without changing the default Git-based dependency flow. Registry support should be additive and opt-in while the API stabilizes, which is why it is proposed behind an experimental flag.
A registry-backed flow gives organizations a path to use existing artifact management, access control, audit, retention, and promotion workflows for APM packages. The initial scope can focus on install-time resolution and documented HTTP API compatibility; publishing and package lifecycle management can remain future extensions.