Promote here means moving a second-generation managed package version from beta to released using the Salesforce CLI. Do this only when the version is fully tested and every dependency is itself released.
- Authenticate to the Dev Hub
Log in to the Dev Hub org that owns the package, since promotion is authorized against that hub. Confirm you are targeting the right hub before continuing.
- Identify the exact version
Find the package version id or the package alias and version number you intend to release. Promoting the wrong version is the most common and least recoverable mistake.
- Run the promote command
Run sf package version promote and pass the version. The CLI prompts for confirmation because the change is effectively permanent. Approve it only when you are sure.
- Verify the released status
Confirm the CLI reports the version as released. Optionally install it in a fresh test org to prove it is now production-installable before you distribute the link.
The package version alias or subscriber package version id you want to promote to released.
Skips the confirmation prompt, which is useful inside a CI pipeline once a human approval gate has already passed.
The Dev Hub username or alias that owns the package, when it is not your default hub.
- Promotion is treated as one-way; reverting a released version to beta is a narrow Salesforce support exception, not a normal undo.
- A version with a beta dependency cannot be installed cleanly in production, so promote dependencies first.
- Promoting does not list the package on AppExchange; that still requires a separate security review for public distribution.
- Beta versions cannot be upgraded, so never install a beta in a release-pipeline sandbox like UAT or staging.