microsoft/winget-pkgs: The Manifest Repository Behind winget install

What winget-pkgs actually is, and what it is not

This repository contains the manifest files for the Windows Package Manager default source. That single sentence from the README defines the boundary. The manifests live here; the client that reads them lives in a separate repository, microsoft/winget-cli, which the README describes as an open source client designed for command-line usage. If you are looking for a program to install on a Windows machine, this is the wrong repository to clone. If you are looking for the data that makes winget install resolve a package name to a download URL, this is exactly the right one.

The practical consequence is that the repository is mostly YAML. The manifests/ directory holds the package definitions, schemas/ holds the JSON schemas those definitions are validated against, and Tools/ holds the validation code that the continuous integration pipelines run. The DevOpsPipelineDefinitions/ directory contains the pipeline definitions that wire those pieces together. A contributor's job is to produce a manifest that passes schema validation and points at an installer that actually exists. A consumer's job is to run the client. Those two jobs never meet inside this repository.

Who this is for, then: application maintainers and community contributors who want a package reachable through the default source, and engineers who need to understand why a given package behaves the way it does in the client. It is not a registry API, not a CDN, and not a place where binaries are stored.

How a manifest becomes an installable package

The data flow is short and worth stating plainly. A contributor writes a manifest under manifests/, the schema in schemas/ constrains its shape, the tools in Tools/ validate it, and the pipelines defined in DevOpsPipelineDefinitions/ run that validation on pull requests. Once merged to the master branch, the manifest is part of the default source that the client reads.

The README is explicit about what the manifest may point at. Installers must be MSIX, MSI, APPX, MSIXBundle, APPXBundle, or .exe application installers. Font files (.ttf, .ttc, .otf, .otc, and .fnt) are also supported, although the README states that community submissions for fonts are not currently being accepted. Script-based installers are not currently supported. That last constraint disqualifies a large class of developer tooling that ships as a shell script or a PowerShell bootstrap, and it is the single most common reason a submission is the wrong shape for this repository rather than a rejected one.

The validation model is the interesting design choice. Because the repository holds only descriptions, the pipeline can check that a manifest is well formed and that its fields are consistent, but the artifact it describes is fetched from somewhere else at install time. The repository is therefore a trust and consistency layer, not a distribution layer. That distinction explains why the README leans on a Contributor License Agreement and a code of conduct rather than on hosting terms: the thing being contributed is a description with a URL in it.

Getting the client and finding what the repository publishes

Nothing here is installed from this repository. The client is distributed separately, and the README points to microsoft/winget-cli as the open source client. The README does not document client commands, so the place to look for how to search, install or list packages is the client's own documentation rather than this repository.

What this repository does document is the contributor path. The README routes readers to doc/README.md for authoring a manifest, testing a manifest and submitting a manifest, and to doc/FirstContribution.md for the first-time contributor checklist. It also lists doc/Issues.md for requesting a new package and for requesting a new package version, which is the route to take when you want a package added but are not writing the manifest yourself.

If you are preparing a submission, comparing your draft manifest against an existing one for a similar application under manifests/ is faster than reading the schema cold. The schema files under schemas/ are the authority on which fields are required and which installer types are permitted. For people who want a private source rather than the community one, the README links doc/private/README.md, which covers private WinGet package hosting. That is a different deployment model: you host the manifests and the client is pointed at your source instead of the default one.

The installer-type restriction is the real gate

Most complaints about this repository trace back to one line in the README: script-based installers are not currently supported. A tool distributed as a curl pipe, a Chocolatey script, or a custom bootstrapper cannot be represented as a manifest here, no matter how popular it is. The supported set is enumerated and closed: MSIX, MSI, APPX, MSIXBundle, APPXBundle, .exe, plus font formats that are not open to community submission yet.

There is a second, quieter limitation. A manifest describes where to get an installer; it does not guarantee that the installer stays there. If a vendor moves or removes a download URL, the manifest that pointed at it becomes stale, and the failure surfaces to users at install time rather than at review time. The README does not document any automated liveness check on installer URLs, so treat URL stability as the contributor's responsibility. Vendors who version their download paths per release, or who gate downloads behind a redirect that changes, will find this repository a poor fit for their release cadence.

The third limitation is scope of acceptance. The README encourages submissions but also states that you may not make submissions linking to third-party materials if that submission is prohibited by the applicable third party or otherwise violates their rights. Redistribution-adjacent packages, or installers whose terms forbid linking in this manner, are out of bounds regardless of technical validity. That is a policy constraint, not a schema one, and no amount of manifest correctness works around it.

How this differs from Chocolatey and Scoop

The closest alternatives are Chocolatey and Scoop, and the difference is architectural rather than cosmetic. Chocolatey packages are themselves installable artifacts: a package contains the logic, often PowerShell, that performs the installation, so the community can wrap almost anything, including script-driven tools that have no native installer. Scoop follows a similar model with a focus on portable applications and a per-user installation directory, and it also permits package definitions that carry their own install logic.

winget-pkgs takes the opposite position. It stores descriptions of native installers and delegates the actual installation to the vendor's own MSI, MSIX or .exe. The upside is that the vendor's installer, with its own upgrade and uninstall behaviour, runs unchanged. The downside is the restriction described above: if there is no native installer, there is no manifest. A team that needs to distribute a tool with no MSI and no .exe has a straightforward answer here, and it is to use a system that permits scripted packages rather than to fight the schema.

A second difference is the source model. The default source is curated through pull request review against schemas in this repository, which means the manifest format is uniform and machine-validated. Chocolatey and Scoop communities have their own conventions and their own review processes, but the manifest shapes are not interchangeable with the ones under manifests/ here.

Maintenance, licensing and the cost of staying current

The repository is not archived. No last push date is given, so no statement about how actively it is updated can be made here; check the commit history directly if that matters to your decision. What can be said is structural: because the repository holds manifests rather than code, its ongoing cost is dominated by the volume of package version updates rather than by feature work. Every upstream release that a contributor wants reflected requires a manifest change and a pull request.

The licence is MIT. That covers the repository contents, and it is a permissive licence with no copyleft obligation on downstream users of the manifests. It does not extend to the applications the manifests point at; those carry their own licences, and the README's restriction on linking to third-party materials that prohibit such linking sits alongside the MIT grant rather than being overridden by it. This is a description of what the README states, not legal advice; if your distribution terms are unusual, the question is for your own counsel.

Contribution overhead is real and worth budgeting. The README states that most contributions require agreeing to a Contributor License Agreement, and that a CLA bot will determine whether you need to provide one and decorate the pull request accordingly. You sign once across Microsoft repositories using that CLA. Between the CLA step, the first-time contributor checklist in doc/FirstContribution.md, and validation before submission, a first manifest is a small project rather than a five-minute task. Subsequent version bumps for the same package are considerably cheaper.

Editorial conclusion

Adopt winget-pkgs as a contribution target if you ship an MSIX, MSI, APPX, MSIXBundle, APPXBundle or .exe installer and want it reachable through the winget default source; the README states script-based installers are not currently supported, so projects distributed only as shell or PowerShell scripts are the wrong fit. Do not treat this repository as a hosting service for your binaries: manifests point at installer URLs, and the README warns that submissions linking to third-party materials prohibited by that third party are not allowed. Before opening a pull request, read doc/FirstContribution.md, run the validation path under Tools/ against your manifest, and confirm your installer URL is stable and publicly reachable, because the validation pipeline checks the manifest rather than the long-term availability of the download.

Frequently asked questions

Official sources

1. Official README
2. Project repository