Package publishing

How publishing works

You add a package once. Every release tag you push to the connected repository is picked up automatically, checked, packaged, and made available to buyers.

Add a package

Open My packages, then Add. Pick from the list of connected repositories where possible. That option pre-fills the composer name from the repository and sets up the webhook for you. If your operator has enabled the paste-URL tab, you can also paste a Git URL by hand; that path does not auto-register a webhook.

The wizard reads metadata from your repository, so the fields you fill in are deliberately minimal:

• Composer name: only needed in the paste-URL flow. The canonical vendor/package form. It must match the name field in the composer.json of your tagged releases. The connected-repo flow takes this from the repository.
• Pricing: free, one-time, or subscription. See Pricing. Paid and subscription packages stay invisible to buyers until your Stripe Connect onboarding is finished.
• Visibility: public, or hidden dependency if this package only exists to support a bundle. See Metapackages.
• Optional overrides: a short description, categories, and currency. Everything else (the package type like magento2-module / metapackage / library, the README, the CHANGELOG) is read straight from each tagged release.

Activation and review

On marketplaces that require per-package review, a new package starts as pending and buyers cannot install it yet. Tags you push during that time still ingest in the background, so the package is ready to go live the moment Packagento marks it active. Most marketplaces run with vendor-level approval only, in which case packages activate on creation and the per-package review step does not apply. Your operator can tell you which mode this marketplace uses.

If a package is taken offline later (policy reasons, abandoned, or by your own request), every release goes offline together. There is no per-release disable for vendors.

Tag a release

Releases are driven by Git tags. Push a strict semver tag (v1.4.2 or 1.4.2) and Packagento picks it up: it fetches your composer.json, README, and CHANGELOG at that tag, then queues the release for the automated checks.

Non-semver tags such as nightly, latest, or staging are ignored on purpose so a buyer cannot install one. Pre-release suffixes like -alpha, -beta, -rc1 are honoured as semver pre-releases; whether buyers see them depends on the minimum-stability rule (see the visibility section below).

Automated checks

Every release runs through four automated checks:

• PHPCS against the Magento2 coding standard.
• PHPStan static analysis.
• Security audit (composer audit against published advisories).
• Copy-paste detector.

The release is packaged into an installable archive regardless of the per-check outcome. Whether buyers can install a release whose checks failed depends on your operator's policy: some marketplaces serve every release and treat the check results as a quality signal vendors can act on, while others hide releases until every check passes. Per-rule failure detail appears on the release page either way, so you can see exactly what to fix and where.

When buyers can install a release

A release is available to a buyer only when all of the following are true:

• Your vendor account is approved.
• The package is active (it has not been taken offline, and, on marketplaces that require it, per-package review is complete).
• The buyer has an active licence for the package, or the package is free.
• For subscription buyers: the release was tagged on or before the date their access window closes.
• The release's stability matches the marketplace's minimum-stability setting (default stable). Pre-release tags are filtered out by default and only appear when the operator relaxes that setting.
• When the operator has chosen to hide check-failed releases, the automated checks for the release have passed.

If a buyer says a release is missing, walk this list top to bottom. Usually one of the first three explains it.

Track progress on your activity feed

Every tag generates entries in your activity feed. You can see when a release was picked up, whether the checks passed or failed, and when the archive was built. If a release shows as ingested but never finishes the checks within a few minutes, contact support.

Ship a fix

To replace a broken release, tag a new semver version with the fix and push. Buyers on a constraint like ~1.4.0 will pick up 1.4.3 on their next composer update. Buyers pinned to 1.4.2 stay on that release until they bump.

Packagento does not delete past releases, because Composer needs every published version to remain resolvable so that historical lockfiles keep working. If a release is dangerously broken (security or data loss) and you need it pulled urgently, get in touch through our contact form so the whole package can be taken offline while you ship a corrected release.

Troubleshooting

• Tag pushed, no release row: check the tag is a strict semver. See Repository ingest webhooks for delivery diagnostics.
• Checks stuck pending: most runs finish in under five minutes. Allow longer for large modules. If a release is still pending after an hour, contact support.
• Checks failed: open the release page; the quality tab lists each rule, the file, and the line that failed.
• Everything green, buyer still cannot install: walk the visibility list above. Most often the buyer's subscription window has passed the release date, the tag is a pre-release that the minimum-stability rule filters out, or the package has not been activated yet on a marketplace that requires per-package review.