# NuGetGallery is the code that runs nuget.org

> The NuGetGallery repository holds everything behind the .NET package gallery, the web application, a set of shared service libraries and the background jobs including the implementation of the NuGet V3 API. It is a Microsoft and .NET Foundation codebase that expects Visual Studio on Windows, and it is a strange fit for anyone who simply wants to publish a package.

**NuGet/NuGetGallery** — NuGet Gallery is a package repository that powers https://www.nuget.org. Use this repo for reporting NuGet.org issues.

- Repository: https://github.com/NuGet/NuGetGallery
- Website: https://www.nuget.org/
- Stars: 1,650 · Forks: 664
- Language: C#
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/nuget-nugetgallery

## This is the gallery, not the client

The repository description sets out the scope precisely. NuGet Gallery is a package repository that powers nuget.org, and the repository itself is for reporting nuget.org issues.

The distinction matters, because there are two separate repositories and confusing them wastes time. This one is the server side. The README points to the Home repository for information about NuGet itself, which is where the client, the command line and the package format documentation live.

The audience is therefore a contributor to a public service rather than a developer who wants to publish a package. The README is explicit about that in the contribute section: if you find a bug with the gallery, visit the issue tracker, and if you are feeling generous, search to see if the issue is already logged before creating a new one. The instructions for a good issue are specific, and they are a decent template for any bug report. Explain what you were trying to do, what you expected to happen, what actually happened, and the steps to reproduce the problem, and include information relevant to reproduction such as the browser version you used, and whether it happens when you switch browsers.

The licence is Apache 2.0 with the copyright held by the .NET Foundation, and the project has adopted the Microsoft Open Source Code of Conduct, with the code of conduct FAQ and an opencode@microsoft.com address for questions. There is also a trademarks section that says use of Microsoft trademarks or logos in modified versions of the project must not cause confusion or imply Microsoft sponsorship, and that third party trademarks remain subject to their own policies.

The repository is not archived and the last push was on 2026-10-18, though the tagged releases are older, with v2024.12.06 and v2024.12.05 from December 2024 and v2023.04.25 before them.

## Local development means Visual Studio and LocalDB

The getting started section is explicit about the prerequisites, and the first line is the one that decides whether you can proceed at all.

You need Visual Studio 2022, with the ASP.NET and web development workload and the Azure development workload. For the web UI functional tests you also need the Web performance and load testing tools component. Visual Studio 2019 may work, but Visual Studio 2022 is recommended. The Azure development workload is what installs SQL Server Express LocalDB, which is the database configured for local development.

That last point is the important one. There is no documented alternative database for local development, and the setup script creates it.

The steps to run the gallery web app are short.

```bash
git clone https://github.com/NuGet/NuGetGallery.git
```

Then you navigate into the `NuGetGallery` directory, build with `build.ps1`, create the database and enable HTTPS with `tools\Setup-DevEnvironment.ps1`, open `NuGetGallery.sln` in Visual Studio, and make sure the `NuGetGallery` project is the start-up project before pressing F5 to run the site.

The repository contains both the gallery web app, which is what runs nuget.org, and the background jobs and shared libraries. The documentation directory covers frontend development, using AAD for authentication, and more.

The Git workflow section adds one detail that is easy to miss. You clone and check out the `dev` branch, and Visual Studio may modify the `applicationhost.config` file, which is a local artefact of running from Visual Studio rather than something to commit.

## Three solutions, three kinds of work

The repository is organised around three Visual Studio solutions, and which one you open tells you what you are working on.

`NuGetGallery.sln` is the web application, the thing that serves the public site. `NuGet.Jobs.sln` is the background work, and the README notes that this repository contains nuget.org's implementation of the NuGet V3 API as well as many other back-end jobs for the operation of the site. `NuGet.Server.Common.sln` is the shared library set.

The shared libraries are listed by name, and the list explains why they are separate. There is `NuGet.Services.Configuration`, `NuGet.Services.KeyVault`, `NuGet.Services.Logging`, `NuGet.Services.Owin`, `NuGet.Services.Cursor` and `NuGet.Services.Storage`, described as a set of shared libraries used across the NuGet server repositories.

Working on them is a three step process. You build with `build.ps1`, you open `NuGet.Server.Common.sln` in Visual Studio, and you create the validation database by opening the Package Manager Console, setting `NuGet.Services.Validation` as the default project and running `Update-Database`.

The note at the end of that section explains why the shared projects also appear in the other solutions. Many of them are referenced by the other solution files in the root of the repository, to simplify modification, which means a change to a shared library can be made from whichever solution you happen to have open.

There are also functional test solutions in the root, `NuGetGallery.FunctionalTests.sln` and `NuGet.Jobs.FunctionalTests.sln`, along with a newer `NuGetGallery.Aspire.slnx` and the usual build plumbing in `build.ps1`, `build.shared.ps1`, `test.ps1`, `global.json` and `Directory.Packages.props`.

## A background job is an exe with two classes

The background job contract is the clearest piece of onboarding documentation in the repository, and it is worth quoting because it tells you exactly what a new job has to look like.

Each job would be an exe with two main classes, `Program` and `Job`. `Program.Main` should simply do the following and nothing more.

```csharp
var job = new Job();
JobRunner.Run(job, args).Wait();
```

The `Job` class must inherit `JsonConfigurationJob`, and the documentation explains why. This job base provides some dependency injection setup and has you set configuration in a JSON file.

Most jobs can be run locally with a `-Configuration {path_to_json}` command line argument, although not all follow this pattern. For the ones that do not, the documentation says to check the implementation in `Program.cs` or the `README.md` next to the `.csproj` project file for job specific information.

That last convention is worth noting. The per project README next to the project file is where the exceptions are documented, which means the odd job out is not a defect but a case of the general pattern not applying.

The repository also carries the pieces a large .NET service accumulates. There is `CodeQL.yml` and `CredScanSuppressions.json` for the security tooling, `sign.thirdparty.props` for third party signing, `RemovedPackages.md`, `python/` alongside the .NET code, `.pipelines/` for the pipeline definitions, and `content/` for the static content the site serves.

## Deploying to Azure, or to a folder with IIS Express

There are two documented deployment routes, and the local one is unusual enough to be worth reading in full.

Deployment to Azure has its own instructions in `docs/Deploying/README.md`.

Deployment locally is done with a publish profile. You select the `NuGetGallery` project in Solution Explorer, right click it, choose Publish, create a publish profile and make sure the Target is set to Folder. You then copy the contents of the Target Location to any folder you want, and the example in the documentation assumes `C:\ContosoSoftware\NuGetGallery`.

The site is then started with IIS Express.

```cmd
"C:\Program Files\IIS Express\iisexpress.exe" /path:C:\ContosoSoftware\NuGetGallery
```

The documentation notes that the `/path` parameter of iisexpress.exe only supports absolute paths on Windows, and that once deployed you do not need Visual Studio to run the site. The local website is then reachable at `https://localhost`.

So the whole deployment is a folder publish plus one command, which is a genuinely simple story for something that is the public package gallery for the .NET ecosystem. It is also a Windows-only story, since the tool, the paths and the quoting are all Windows specific.

The contributing section closes the loop on how changes get in. Before starting work on an issue, either create an issue or comment on an existing one to make sure everyone is communicating. There is a list of good first issue items, with the instruction to always ping the maintainers beforehand. Then you make a fork, follow the Git workflow, and send a pull request.

## Conclusion

NuGetGallery suits a Microsoft employee or a .NET Foundation contributor who wants to work on the public package gallery, and a platform team that needs to understand how nuget.org is built before operating something like it. It is the wrong repository for publishing your own packages, since the NuGet client and the gallery protocol are documented separately in the Home repository, and the wrong choice for a team on a non-Windows machine. Check first that you have Visual Studio 2022 with the Azure development workload, because the local database is SQL Server Express LocalDB and there is no documented alternative.

## FAQ

### What does the NuGetGallery repository contain?

It contains the gallery web app that runs nuget.org, the background jobs including nuget.org's implementation of the NuGet V3 API, and a set of shared service libraries used across the NuGet server repositories. For information about NuGet itself, the README points to the separate Home repository.

### What do I need to run the NuGet Gallery locally?

Visual Studio 2022 with the ASP.NET and web development and Azure development workloads, plus the Web performance and load testing tools component for the web UI functional tests. The Azure development workload installs SQL Server Express LocalDB, which is the database configured for local development.

### How is a NuGet Gallery background job structured?

Each job is an exe with two main classes, `Program` and `Job`. `Program.Main` should only create the job and call `JobRunner.Run(job, args).Wait()`, and the `Job` class must inherit `JsonConfigurationJob`, which provides dependency injection setup and JSON file configuration. Most jobs run locally with a `-Configuration {path_to_json}` argument.

### How do I report a bug in nuget.org?

Use the GitHub issue tracker for this repository, and search first to see whether the issue is already logged. The README asks for a clear explanation of what you were trying to do, what you expected to happen, what actually happened, and the steps to reproduce, along with details such as the browser version and whether the problem happens when you switch browsers.

## Sources

- [License: Apache-2.0](https://github.com/NuGet/NuGetGallery/blob/main/LICENSE)
- [NuGet/NuGetGallery on GitHub](https://github.com/NuGet/NuGetGallery)
- [Project website](https://www.nuget.org/)
- [README](https://github.com/NuGet/NuGetGallery/blob/main/README.md)
- [Releases](https://github.com/NuGet/NuGetGallery/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/nuget-nugetgallery