Create SharePoint Site Collection App Catalog: What You Need to Know

Worth a direct correction before anything else: the verification cmdlet that circulates for confirming a site collection app catalog was actually enabled — `Get-SPOSiteCollectionAppCatalogsSite` — doesn’t exist. The real cmdlet is `Get-SPOSiteCollectionAppCatalogs` (no trailing “Site”), and a script built around the wrong name fails with a generic “command not recognized” error that gives no hint the fix is just a typo. This post covers the corrected setup, the one real prerequisite most walkthroughs skip, and a worked example of what actually breaks if it’s missing.

In this post: The prerequisite most guides skip · Enabling it, the corrected way · The PnP PowerShell equivalent · What actually shows up once it’s enabled · A real failure mode worth knowing · Removing it doesn’t do what the name suggests · Governance worth setting up front · Related reading

The prerequisite most guides skip

Worth confirming before running anything below: a tenant app catalog needs to already exist in the tenant before a site collection app catalog can be enabled at all. This is genuinely easy to miss in a brand-new or recently-provisioned tenant, since the site collection catalog is a separate, additive feature layered on top of the tenant catalog’s existence, not a standalone replacement for it. `Get-PnPTenantAppCatalogUrl` (or checking the SharePoint admin center’s More Features page) confirms one exists before spending time troubleshooting what looks like a permissions error but is actually a missing prerequisite.

Get-SPOSiteCollectionAppCatalogs — no trailing “Site” — is the real cmdlet name. The version with “Site” appended shows up often enough in examples of this pattern that it’s worth double-checking against Microsoft’s own current documentation rather than copying from the first result that comes up.

Enabling it, the corrected way

Connect-SPOService -Url https://yourtenant-admin.sharepoint.com

Add-SPOSiteCollectionAppCatalog -Site https://yourtenant.sharepoint.com/sites/YourSite

# Verify -- correct cmdlet name, no trailing "Site"
Get-SPOSiteCollectionAppCatalogs -Site https://yourtenant.sharepoint.com/sites/YourSite

An empty result from the verification call means the catalog genuinely isn’t enabled on that site — worth checking this explicitly rather than assuming the `Add-SPOSiteCollectionAppCatalog` call succeeded just because it didn’t throw an error, since a missing tenant app catalog (the prerequisite above) can cause it to silently not take effect.

The PnP PowerShell equivalent

Connect-PnPOnline -Url "https://yourtenant.sharepoint.com/sites/YourSite" -Interactive

Add-PnPSiteCollectionAppCatalog -Site "https://yourtenant.sharepoint.com/sites/YourSite"
Get-PnPSiteCollectionAppCatalog -Site "https://yourtenant.sharepoint.com/sites/YourSite"

Worth defaulting to the PnP version for anything running cross-platform or alongside other PnP-based deployment scripts — `Connect-SPOService` and the `Get-SPO*`/`Add-SPO*` family are Windows-only (SharePoint Online Management Shell), while PnP PowerShell runs identically on Windows, macOS, and Linux.

What actually shows up once it’s enabled

A new “Apps for SharePoint” library appears in the site’s content — `.sppkg` package files get uploaded there directly, the same way they’d be uploaded to the tenant catalog, just scoped to this one site collection. Deploying from that point forward is the same `Add-PnPApp -Scope Site` pattern covered in this site’s tenant-vs-site-catalog comparison, not a separate mechanism.

Worth checking the “Apps for SharePoint” library’s permissions explicitly once it’s created, rather than assuming it’s locked down by default: it inherits the site’s standard permission structure, which means anyone with Contribute access or higher to the site can upload a package to it, not just whoever originally enabled the catalog. Breaking inheritance on that specific library and restricting upload rights to a smaller, deliberate group is worth doing before treating the catalog as production-ready, since the library itself doesn’t apply any additional access restriction on top of whatever the site’s general permissions already allow.

A real failure mode worth knowing

Worth knowing this specific gotcha before it causes a confusing investigation: if the same app already exists in the tenant catalog and later also gets uploaded to a site’s own catalog, the site-scoped copy takes precedence on that specific site, even over a newer tenant-wide version. A team that enables a site collection catalog for quick local testing, then forgets to remove the test copy once the tenant-wide version ships, ends up permanently stuck on the old test build on that one site — worth cleaning up test deployments explicitly (`Remove-PnPApp -Scope Site`) rather than leaving them in place once they’ve served their purpose.

Removing it doesn’t do what the name suggests

Worth a direct correction on the cleanup side too: `Remove-SPOSiteCollectionAppCatalog` doesn’t actually remove the “Apps for SharePoint” library or delete its contents, despite the name — it disables the site from accepting new solution deployments going forward, while the library and whatever’s already in it stay put and visible:

Remove-SPOSiteCollectionAppCatalog -Site https://yourtenant.sharepoint.com/sites/YourSite

Worth checking the library directly afterward if the goal was a genuinely clean removal rather than just stopping future deployments — the cmdlet’s name implies a full teardown that it doesn’t actually perform.

Governance worth setting up front

Decide up front who’s allowed to enable a site collection app catalog — Site Collection Administrator rights are enough technically, which means the actual limiting factor is policy, not the platform.
Track which sites have their own catalog enabled somewhere central — there’s no single tenant-wide report listing every site collection catalog in one place, so this needs to be tracked deliberately rather than assumed discoverable later.
Treat a site-scoped catalog as genuinely temporary for anything meant to eventually go tenant-wide — the precedence gotcha above is the concrete cost of treating it as a permanent parallel deployment instead.

Tenant-Wide vs Site Collection App Catalog: What You Need to Know — the decision framework for choosing between the two, including the Teams-sync limitation that makes the tenant catalog non-optional in some cases.
Start Your SharePoint with SPFx — building the `.sppkg` package this catalog hosts, using the current Heft-based toolchain.

The setup itself is two commands once the tenant app catalog prerequisite is confirmed — the part actually worth getting right is everything that happens after: verifying the catalog actually took effect with the correctly-named cmdlet, restricting who can actually upload to the resulting library rather than trusting the site’s default permissions, and cleaning up test deployments before the precedence rule turns a forgotten site-scoped copy into a permanent, confusing exception to whatever the tenant catalog says should be running.