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

Hi @Ashley ,

Good news -- this will be fixed via PG-3265 in the upcoming maintenance release (next Friday).

In case you're curious, the bug was that we were comparing packagePublished.AddDays(recentlyPublishedDays.Value) > DateTime.UtcNow.Date, which includes the time-portion on the left side, but not the right-side (so 12:00A).

Just changing to packagePublished.Date.AddDays(recentlyPublishedDays.Value) > DateTime.UtcNow.Date does the trick, and it works for both Aged and Recently Published.

cheers,
Alana

Hi @stno_9153 ,

Thanks for clarifying; that's not possible with ProGet. A Debian feed is not designed to be a "read-only mirror", but instead a repository where you can add/filter/update packages. So, that's why ProGet must generate/sign the (In)Release files.

I'm afraid we have no plans to support a read-only mirror use case in the forseeable future.

Cheers,
Alana

Hi @stno_9153 ,

(In)Release files are signed using a private/public key scheme, so unless you were somehow able to get a copy of Ubuntu's private signing keys and upload it to ProGet... it is not possible to sign those files using the original Ubuntu Key.

Cheers,
Alana

Thanks @Ashley, that's exactly what I was thinking.

I haven't tried reproducing this yet, but I've got all the steps to now! And at that point, I'll have a debugger and all the code in front of me, so it should be an easy fix. It's probably related to UTC/local time, I don't think we've ever tested it "by the hour" like that :)

Anyway stay tuned we'll get it fixed pretty soon.

Hi @stno_9153 ,

Oh yeah, that'll make a HUGE difference for public repositories. OTherwise it'll probably not work at all :)

Anyway glad it's working now

Thanks,
Alana

Hi @Ashley ,

To set override the publish date, first Pull the package to ProGet so that it's no longer a cached package. Once you do that, you will see a "Set Package Status" option (you may need to refresh page). On that modal dialog, select "Override Metadata..." and enter the date.

That's what we do to test these rules; note you can delete the package and re-download it to cache it again.

Let me know if you spot anything off, it seemed to work for me, but I might be looking at the wrong things.

Thanks,
Alana

Hi @stno_9153,

If the error happened during a apt update of hundreds of packages, then it probably was a case of server overload. Make sure to set a lower concurrent rate, which you can do under Admin > HTTPS SEttings > edit. 100 is the recommendation, and will be the default in ProGet 2026.

Thanks,
Alana

Hi @brandon_owensby_2976,

Argo CD is free / open source and no license is required. You'd be better off learning that than trying to do Kubernetes another way. FYI there's also Kargo, which is a "wrapper" that sits on top of ArgoCD and has some kind of promotion workflow outside of typical GitOps (pull requests I guess?).

To be honest, I really don't know if the Kubernetes extension even works; it was originally intended for Otter, to create a "Desired state" and offer an alternative to Git-based approaches. But there's just no demand and GitOps is just the Kubeernetes standard. We haven't tested it in years.

We do not plan on migrating it to the next SDK version. It's just a light wrapper around kubectrl, which has probably changed over the years. If you really wanna mess with Kubernetes outside of Argo CD I would just run kubectrl apply/replace directly.

Good luck!!

Hi @ashleycanham ,

The min-release-age setting in npm and ProGet's "Recently published" are unrelated. One controls how the client (npm) behaves, the other controls how the server (ProGet) behaves.

I'm not an expert on min-release-age on the client (npm) side, but I believe it changes the way the dependency resolution algorithm works. In turn, that means npm will request different packages from the server. That's why changing that value will yield different server results.

On the server (ProGet) side, ProGet effectively blocks package downloads by looking at the publish date (which you can see on the history page, and even set/change on the Set Package Status Page) against the current server date time. This is obviously indicated by "Download Blocked" in your screenshot, but more precisely it has to do with "package compliance".

There's a lot involved with that, but if you Reanalyze the Package, you can get detailed logs of what's making the package Noncompliant. Specifically, in those logs, you should see something like this:

Policy "{policy.Name}" considers recently published ({recentlyPublishedDays} days) {rule}
Publish date of {package.Published.Value.Date:d} is considered recently published.

That date will be UTC-based (the UI typically displays local time, i.e. BST), but you'll get an idea of how it works.

Anyway, that's where I would start. Considering timezones, rounding, or partial days, you may find it simply easiest to set min-release-age=8 so that npm isn't requesting a package that's 6.99999 days old, or something weird like that.

One last thing worth mentioning, we are no longer recommending blocking noncomplaint packages in most cases. Instead, using pgutil builds scan can be used to "Break builds" and give a much clearer output, so that developers don't have to chase down npm error logs.

Thanks,
Alana

Hi @stno_9153 ,

If you're getting an error downloading a .deb file, it wouldn't be related to the feed/connector indexes (i.e. those In/Release files).

When you request a .deb file, ProGet will first check if the file is stored (cached) locally. If so, then it will send them file. Otherwise, it will "forward" the request to the connector and stream the file to you while saving on disk, so that it's cached for next time.

A timeout typically is related to network or hardware errors. The first thing I would work on is reproducing and isolating where theh error is occuring. You can delete cached packages from the feed using the UI, and also download files that way.

I would just use curl to test downloads.

Let us know what you find!

Thanks,
Alana

Hi @kien-buit_2449 ,

Thanks for sharing the details. I was able to confirm this is some kind of bug (data problem?) in ProGet. It appears to be in the datafile that's downloaded/imported into ProGet, though I'm not sure.

Stay tuned, and we'll let you know once a fix is ready.

Thanks,
Alana