If an application you want to install or patch through Atera isn't available in the WinGet (Windows Package Manager) public repository, you can request it or submit it yourself. The WinGet catalog is maintained by Microsoft and the community in the microsoft/winget-pkgs GitHub repository. This article explains both ways to get a missing app package added: opening a package request, or creating and submitting the manifest yourself.
Important: The WinGet repository is managed by Microsoft and its community moderators, not by Atera. Atera doesn't control whether a submission is approved or how long the review takes.
Option 1: Request a package
Requesting a package is the fastest option if you want an app added but don't want to build the WinGet manifest yourself.
- Go to the microsoft/winget-pkgs repository on GitHub.
- Open a new issue and select the Package Request/Submission template.
- Fill in the application details and submit the issue.
A community contributor or the app's publisher can then pick up the request and submit the manifest. There is no guaranteed timeline for requests to be fulfilled.
Option 2: Submit a WinGet package yourself
You can create and submit a WinGet manifest yourself to control the timing. Complete the steps below in order.
Before you begin
You'll need:
- A GitHub account.
- WinGet installed on the machine you'll use to validate the manifest.
- A publicly available download URL for the application's installer. Anyone can submit a manifest, and you don't need to be the app's developer.
Step 1: Create the WinGet manifest
A WinGet manifest is a YAML file that describes the application according to the Windows Package Manager schema.
You can create a manifest in two ways:
-
Using WingetCreate (recommended): Run
wingetcreate newand follow the interactive prompts to generate the manifest. - Manually: Write the YAML file by hand, following the Windows Package Manager manifest schema on Microsoft Learn.
Step 2: Validate the WinGet manifest
Validate the manifest before submitting it. This catches errors before the automated review does.
- Run
winget validateagainst your manifest file or folder. - If the output reports errors, use the line numbers in the validation output to fix them.
- Run the validation again until it completes without errors.
Step 3: Check for duplicate submissions
Before submitting, search the open pull requests and issues in the microsoft/winget-pkgs repository. This confirms that no one has already submitted the same package or version.
Step 4: Submit the WinGet manifest
You can submit the manifest through GitHub manually, or let WingetCreate do it for you.
To submit manually through GitHub:
- Fork the microsoft/winget-pkgs repository and clone your fork locally.
- Add your manifest under the following folder structure: manifests > first letter of the publisher name > publisher name > application name > version. For example: manifests/c/Contoso/ContosoApp/1.0.0.
- Commit your changes and push them to your fork.
- Open a pull request against the main branch of microsoft/winget-pkgs.
To submit using WingetCreate:
Run wingetcreate submit with a GitHub personal access token (PAT). WingetCreate creates the pull request automatically, so you don't need to fork, clone, or push manually.
Step 5: Track the review
After you submit, your WinGet pull request goes through two review stages:
- Automated validation: An automated pipeline validates the manifest and checks that the installer isn't malicious.
- Manual review: A WinGet Community Moderator reviews the submission.
Labels on the pull request show where the submission is in the review pipeline. If the pipeline reports an issue, update your manifest in the same pull request.
Step 6: Merge and availability
Once the pull request is approved and merged, the package is added to the WinGet public catalog. It can then be installed with winget install.
Publisher restrictions on WinGet submissions
Some publishers restrict community submissions for their packages using an Auth.csv file in the winget-pkgs repository. There are two restriction levels:
- "Should" restriction: The publisher is notified about the submission, but the pull request isn't blocked.
- "Must" restriction: The pull request can't be merged until the publisher approves it.
If your submission is blocked by a "must" restriction, you'll need to wait for the publisher to approve it, or contact the publisher directly.