Upload, review and versions

Pack the folder

Create a gzip-compressed tar file (.tgz) of your package folder. The manifest must be at the top level or inside one folder. The upload check refuses:

• files that are not gzip,
• absolute paths, .. paths, symbolic links and duplicate names,
• more than 50 MB for the package, 200 MB unpacked, 20 MB per file, 5,000 files, or paths longer than 240 characters or 20 folders deep,
• .env files and secret-looking strings such as private keys and common token formats.

Never put real keys in a package. Declare the secret's name in secrets and people add their own.

Upload

1. Open Publish, then Upload a package.
2. Under Package file (.tgz, up to 50 MB), choose your file.
3. Choose Upload and check.

You must belong to the publisher named in the manifest.

Reading the answer

If the package is not accepted you get "The package was not accepted" and a What to fix list. Each entry says what is wrong and, where it applies, in which file. Fix them all and upload again.

If it is accepted you see " was accepted", the size and a status:

• Listed: live in the Marketplace.
• Pending review: unlisted until a PGB reviewer approves.

When review applies

Review is required when a version asks for network.outbound, database.write, or business send or share permissions, or contains executable code (scripts, programs, a Dockerfile). Until approval, only you and your team can see it. If it is not approved, the status reads Not listed, and you publish a new version that answers the reviewer's concerns. Packages from PGB itself are approved automatically.

Agents and templates that do not need those permissions and contain no code are listed straight away.

Manage your package

Open Manage on a package, or use Open a package by name for one that is not listed. You will see:

• Review status and a list of Versions.
• Listing details: display name, summary, up to five categories, tags and Visibility (Public or Private).
• Deprecate.

Versions never change

Once published, a version is fixed. To fix or improve something, increase the version number and upload a new .tgz. A version number can never be reused, even after a yank.

Use the usual meaning: 1.0.1 for a small fix, 1.1.0 for a new feature, 2.0.0 for a change that may break people.

Try it yourself

1. Pack your Weekly Summary manifest into a .tgz and upload it.
2. Note whether it is Listed or Pending review. Why?
3. Raise the version to 1.0.1, change the summary and upload again.

Recap

• Upload a .tgz on Publish, then Upload a package.
• The check returns a What to fix list or an accepted result.
• Sensitive permissions and code mean review before listing.
• Published versions are immutable; ship a new version.