Skip to content

Use APM packages

You’re here because you want to install someone else’s APM packages and use them in your project. This is the consumer ramp.

Your situationStart here
First time using APM, just want to try itQuickstart (5 min)
Adding APM to an existing repoInstall packages
You hit Authentication failed for a private repoAuthentication
You need org-private packages or your own marketplacePrivate and org packages
You manage apm.yml and need lockfile / dependency commandsManage dependencies
You want APM to wire MCP servers (GitHub, Atlassian, …) into your toolsInstall MCP servers
You received a local .tar.gz bundle and need to install itDeploy a local bundle
You hit Drift detected after a git pullDrift and secure-by-default
Your org rolled out apm-policy.yml and your install is now blockedGovernance on the consumer ramp

The four commands you’ll use almost every day:

Terminal window
apm init # one-time per project
apm install <pkg> # add a dependency
apm install # restore from apm.lock.yaml
apm run <script> # invoke a script declared in apm.yml

That’s the loop. Everything else is either lifecycle automation (update, outdated, audit) or a workflow extension (MCP servers, local bundles, scripts).

  1. Install packages — the canonical install loop.
  2. Manage dependenciesapm.yml, lockfile, update, outdated.
  3. Run scripts — the script runner that wraps your agent runtime of choice.
  4. Update and refresh — when refs move, when caches go stale.
  5. Stop here unless you hit one of the situational pages above.

If you want to publish a package others can install, switch to the producer ramp. The skills you build there install on the same apm install command everyone here is running.

If you operate a platform team and need org-wide policy, audit, and CI gating, the enterprise ramp is the right entry. Consumer commands are unchanged when policy is enforced — you’ll just see more [x] blocks at install time when something is denied.