Documentation

Catalog & Supply Chain

The catalog decides which apps exist and where each installer comes from. This page answers the supply-chain questions admins ask most.

Where does the catalog come from?

The WinGet community manifests at microsoft/winget-pkgs. A scheduled sync reads versions, installer URLs, SHA-256 values, and locale variants into the IntuneGet catalog.

Does IntuneGet mirror winget like cdn.winget.microsoft.com/cache?

No. IntuneGet does not run a CDN mirror of winget and does not host installer binaries. The catalog stores metadata; the installer is fetched from its upstream vendor URL at packaging time and discarded afterward.

Do you store the built package?

No. The .intunewin is built on an ephemeral runner, uploaded to your tenant, and then discarded. It is never stored by IntuneGet.

Is there a private catalog?

Not today. The catalog is the public verified set, and you can add your own apps by pointing at a public installer URL. A tenant-private catalog is planned; see the roadmap for status.

Can I use my own source?

Yes, by self-hosting. The catalog is served from a snapshot you can host or point at a local file, so you decide which manifests feed your deployment.

How the sync works

text

winget-pkgs (community manifests)
        |
        v
scheduled sync  ->  IntuneGet catalog (metadata + SHA-256)
        |
        v
packaging run   ->  fetch installer from vendor URL, verify SHA-256, discard

WinGet is a community source

Anyone can submit a manifest. A manifest is a pointer to a vendor installer plus a hash, not a guarantee about the vendor. If that risk profile does not fit your organization, self-host and point IntuneGet at your own catalog rather than the public one.

How a package is built and verified See the roadmap microsoft/winget-pkgs

Self-hosting is the way to keep the catalog and the pipeline entirely inside your infrastructure. Start with the Docker guide.