Update 6/22 (2:15 P.M PST): We have a lot of feedback coming in from the community on this topic. This change will not have any impact for another 90 days at the minimum. We are reviewing your feedback and will discuss further how to achieve our goal of improved security of NuGet.org.
Post by this author
A few weeks back, we deployed our consolidated REST API powering NuGet.org and the NuGet client experience in Visual Studio. An invisible change for our users, but a big change for the NuGet team. This consolidated REST API lays the foundation of our future work on the server side of NuGet.
One of the less visible changes since we released NuGet 3.0 is that NuGet uses a new server “API v3”. This new API is designed around high availability for critical scenarios such as package restore and installing packages. API v3 will be the way forward for NuGet while keeping “API v2”
Since its inception, NuGet supports setting up custom package sources. There’s the default NuGet Gallery, there’s third-party NuGet hosting (see the NuGet Ecosystem), we can use local directories on our hard drive or a network UNC share (like \yourserver\nuget) and there’s the NuGet.Server package that we can use to create our own NuGet server.
Last week, we released our Revised Download Counts and Package Statistics that are now based on the raw logs of our CDN. For this to become reality, we had to also import data from our old statistics data warehouse into the new system.
On the server side we are working on boosting performance, scalability and reliability. We were also in need of a new status page to better communicate the status of the service. Without further ado: meet the new status.nuget.org!
We’re happy with this new incarnation of our status page.
In the last few months we have been hard at work on the NuGet.org backend. One of the things we’ve done is switch to a new CDN. This work is all about reinforcing the foundations of nuget.org so we provide a better service experience and be in a position to build new features reliably.