Thanks for the update! I've noted this in the docs, and linked to this discussion :)

https://github.com/Inedo/inedo-docs/commit/d24087911584bbda833314084a58c2ae1ff41c39

Hello;

That "error" message is to be expected; that's what ProGet returns when you visit to /v2 with a web browser. But the error sounds like a sort of SSL/certificate configuration problem.

After searching for "tls: no renegotiation", here is an article I found about that might help: https://www.digicert.com/news/2011-06-03-ssl-renego/

Hi all, just an update! We will be shipping a potential fix in PG-1783, which adds a new checkbox in advanced settings (unchecked by default):

Close Database Connections Early
EXPERIMENTAL (for debugging/testing only) - As of ProGet 5.3, database connections are left open during the lifecycle of a NuGet API request as a means to reduce overhead; however, this may be causing ProGet to run out of available connections to SQL Server. Set this value true to open/close database connections as needed on NuGet feeds.

We'll update when this is shipped --- but if we can get some folks to verify that this works better (we can't repro, at all ), then we will likely make it the default. Hopefully this will do it. Seems better than raising connection pool limits

If so, then the savings in connection open/close overhead don't seem to make it particularly worthwhile. This "keep open" technique made a ton of differences elsewhere in our software, but since a NuGet API requests may yield a ton of other network requests (via connectors) and block, the pool may be getting drained too quickly...

just a theory, as I mentioned. Anyway hope this helps, stay tuned!!

Thanks!

ProGet has a really cool feature called Semantic Versioning for Docker Container Images, and it works pretty much how you described, but it also enforces that containers have a valid semantic version tag. For example, latest will always refer to the highest, stable-version of a container, and 4 will be the latest stable of 4.x.y

As for "generic archives", check out Universal Packages - they're really powerful, and are like "nuget/maven" but for your own applications and components, and extensible.

This is was addressed in PG-1795, which was released in 5.3.9 just recently!

ProGet will use the v3 (JSON-LD) API when possible, but not all v2 (ODATA) queries can be "translated" to the v3 (JSON-LD) API, and thus they need to be forwarded to the v2 (ODATA) end-point.

ODATA is a general-purpose querying API (like SQL but for the web), so clients do a lot with it (sorting, etc.). The v3 (JSON-LD) API is much more limited. So I recommend you to update the clients.

Hello, for sure!

It's pretty easy; just don't give the Anonymous user any access to your feeds, and then authentication will always be required, either when browsing the ProGet application or using the API (such as Install-Module).

When you use the Register-PSRepository command, you can the Credential option to specify a credential.

This credential can be the name/password of a user inside of ProGet (let's say, Admin:Admin), or it can be username of api with a password of an api key you've configured (so, api:my-secret-key).

@atripp said in Creating PowerShell repository, protecting pull/download by API key:

this credential can be the name/password of a user inside of ProGet

Or a user that's configured in your Active Directory, assuming you have enabled that integration.

Hello; you should see a checkbox, like this.

However, due to a bug (now fixed via PG-1885) the checkbox wasn't being displayed due to a license validation problem.

It will be fixed in the next maintence release, scheduled for later today

Hello;

The Native API is for low, system-level functions, and it's "all or nothing". If you give someone access to Native API, you are effectively making them an administrator, as they can also change permissions and grant admin privileges. So, I don't think you want this. Instead, you'll want to use the Debian API endpoint that we implement.

It's a third-party API format

In order to support third-party package formats types like NuGet, npm, etc., ProGet implements a variety of third-party APIs. We only provide minimal documentation for these APIs, as they are generally either already documented elsewhere. However, you can generally find the basics by searching for specific things you'd like to do with the API, such as "how to search for packages using the NuGet API" or "how to publish an npm package using the API".

So in this case, I recommend to search "how to view and download apt packages".

Hi @imm0rtalsupp0rt ,

Great, thanks! I'll share the pull request with our technical writing members; they handle the HOWTO type articles and may want to add more screenshots, etc. But that intro paragraph will really help them.

Changing the texts is trivial; it'll be implemented via PG-3278 in the next maintenance release of ProGet 2026. FYI I also changed description too:

Chocolatey Community Packages

Cache and filter packages from the Chocolatey Community Repository (CCR).

Cheers,
Alana

Hi @Nils-Nilsson ,

FYI this is available in inedo/proget:26.0.1-ci.7 should you want to give it a shot!

Cheers,
Alana

Hi @Valentijn ,

This looks like some consequence of a platform change (we went from .NET8 to .NET10), but it's hard to say.... I wonder if there's some kind of issue with the mixed bindings (i.e. using port sharing for https, but not for http).

What does your <WebServer> node look like in your configuration file?
https://docs.inedo.com/docs/installation/configuration-files

Can you try it without port sharing? So basically just http://*:8624, https://*:443

Thanks,
Alana

Hi @Ashley ,

It sounds like you're definitely looking in the right place / setting the right configuration. X-Forwarded-For should do the trick, but something as silly as a typo (which I've done several times) will make it not work.

Here are the settings we recommend:

   proxy_set_header X-Real-IP $remote_addr;
   proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
   proxy_set_header X-Forwarded-Proto $scheme;
   proxy_set_header X-Forwarded-Host $http_host;
   proxy_set_header X-Forwarded-Port $server_port;

And as an FYI, here is the code we use to get the ClientIP adddress.

public static string GetClientIPAddress(this AhHttpRequest request)
{
    ArgumentNullException.ThrowIfNull(request);

    var forwardedFor = request.Headers["X-Forwarded-For"];
    if (!string.IsNullOrWhiteSpace(forwardedFor))
    {
        var ips = forwardedFor.Split(',');
        var clientIp = ips.FirstOrDefault();
        if (!string.IsNullOrWhiteSpace(clientIp))
            return stripIpv4OverIpv6(clientIp.Trim().Truncate(50)!);
    }

    return stripIpv4OverIpv6((request.NativeRequest?.HttpContext?.Connection?.RemoteIpAddress?.ToString() ?? request.UserHostAddress).Truncate(50)!);

    static string stripIpv4OverIpv6(string ip)
    {
        if (ip.StartsWith("::ffff:") && ip.Contains('.'))
            return ip["::ffff:".Length..];
        return ip;
    }
}

Although I think the stripIpv4OverIpv6 bits may be relatively new.

Thanks,
Alana

Hi @ybaskar-temp_3339 ,

The "root cause" is relatively easy to answer. The error was occurring on the 10. Block 6.2 Upgrades.sql script, which is simply this:

IF OBJECT_ID('ActionGroups') IS NOT NULL EXEC sp_executesql N'
   IF NOT EXISTS(SELECT * FROM [Configuration] WHERE [Key_Name] = ''Legacy.NoLegacyFeaturesDetected'' AND [Value_Text] = ''True'')
   RAISERROR(''Cannot upgrade to BuildMaster 6.2 unless "Legacy.NoLegacyFeaturesDetected" in Advanced Settings is "True". This can be done by running the legacy features checker.'', 16, 1)
'

Basically it will simply crash unless Legacy.NoLegacyFeaturesDetected is not set to "True". The "Legacy Feature detector" should have set that to "True" if there were no legacy features detected... but perhaps it didn't?

Since you were able to bypass it, I wouldn't worry about it. In the "worse case", legacy data would have been purged during the delete.

Thanks,
Alana

Hi @Ashley,

Thanks for testing it! That was the intended behavior here - to count "days" not "24H blocks". That's a more intuitive pattern in general, as people think "the next day" or "a few days later" and don't really consider the time.

That does lead to some strange behaviors like 2026-05-03 23:59:59 to 2026-05-04 to 00:00:01 being considered "1 day". However, in this use case, I guess we're talking just a difference of hours which isn't going to make a package any "safer" realistically.

Thanks,
Alana

PS good catch on typo, I adjusted it on 2026 branch.

Hi @daniel-mccoy_4395,

Based on what you've described, it sounds like ProGet is indeed blocking downloads; this is visible in the ProGet Web UI with a "Download Blocked" indicator. If you try accessing the download URL, you will in fact get a 400 error.

However, NuGet/Visual Studio aggressively cache package - which means they aren't even attempting to download them. If you clear all the NuGet caches (system, user, http, project, etc), then it should attempt to download then again.

That said, as of ProGet 2026, we no longer recommend downloads. This is one reason, but there are more reasons.

Here's an work-in-progress article that discusses our new guidance:
https://guides.inedo.com/vulnerability-management/containment/

Cheers,
Alana

Hi @carl-westman_8110 ,

Not really... Feeds and Views are a bit different concept and we don't really encourage using the presence in a particular feed as a means to identify whether something has been released. Instead, we'd encourage using Pre-Release Packages & Repackaging
, which make it obvious from simply lookin at the version (i.e. 1.1.1-rc.7 indicates not yet released).

Thanks,
Alana

Hi @certificatemanager_4002 ,

ProGet is licensed per instance (i.e. installation), you will need a separate license if you wish to maintain a production and non-production instances of ProGet. See the official Licenses for Non-production / Testing Environments for more details.

For things like a one-off, cloud-migration, using a Trial license (which you can get from My.Inedo.com) is fine.

Thanks,
Alana

Hi @certificatemanager_4002 ,

Just to clarify the support:

We are planning to upgrade to ProGet 25.x, as we understand that Microsoft SQL Server support will be not supported by the end of the year.

We are currently planning to discontinue SQL Server support in ProGet 2027. It will continue to work in ProGet 2025 and ProGet 2026 regardless of when you use the software.

To answer your questions...

1. You can continue using SQL Server in ProGet 2025
2. Please see Configuring High Availability & Load Balancing, which details the implementation
3. ProGet for Linux is supported in a Docker environment; many users will deploy using Kubernetes, but we do not provide charts or templates... only a Docker Installation Guide that you will need to "translate" into pods, etc
4. ProGet can handle that traffic, though a lot of factors will determine how much server resources are required; I would start with a two-node cluster and evaluate/consider adding more if needed

Thanks,
Alana