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

Thanks! No immediate rush, I'll wait for mainline release :) Best regards Nils Nilsson

Hi Alana, thank you for your reply

@rhessinger Thanks for the response. I am using mcr.microsoft.com/mssql/server:2025-CU2-ubuntu-24.04 as the container image.

Hi, i had already downloaded log4j-core with the "bad" version. I would have expected this to be an immediate action but as you described it is tied to a scheduled job triggered by vulnerability update. Looking at the feed and packages today shows me that the auto assessment of all the downloaded packages was done overnight. But does this mean the auto-blocking will never work the first time a package is downloaded? The auto blocking will always only kick in after the next vulnerability update ?? I hope that logic does not apply to the malicious package blocking as well...

Hi @kien-buit_2449, This is partially fixed in our vulnerability aggregator. You should see alpine vulnerabilities showing up next time your vulnerability updated runs. I also recreated a situation where certain packages may not be removed upon update of the vulnerability. I have created ticket PG-3263 to fix that issue. That fix will be released next week in ProGet 2025.27. Thanks, Rich

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 @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 @christian-georg_5533 , Thanks for sharing the additional context, that makes sense. You are correct -- ProGet is a package repository with SCA as a value-added feature. Most of our users create SBOM because they are required to due to regulations, and but don't find much use outside of that :) Of course we're always interested in expanding features but we aren't really striving for the "central SBOM Repository" use case now. We'll see if there's more demand down the line, feel free to share more information (other products, tools) sinc eit's always good to think about future versions of the product! Cheers, Alana

Hi @parthu-reddy , This does not appear to be a "fat manifest". Two other things are coming to mind. First, are these referenced in any helm charts? If so, they won't get removed unless you delete the helm chart first. Second, how about trying a separate policy, "Delete untagged manifests"? That should clear out these images. Thanks, Alana

Hi @cole-brand_2889 , Wow, I didn't realize that S3 rate-limited like that!! That's good to know. Unless this is something that could be configured as an advanced SDK switch in the S3FileSystem, then I don't think there's much that could/should be done in the ProGet or extension code. After searching the error (and seeing this very post on the first page of Google ), this just seems to be endemic with S3; there's no published rate limit, and even in AWS official blog article the only solutions seem to be "follow the error message and reduce your request rate". There's probably something you can do do on the load-balancer side of things... reducing concurrent requests, etc. Let us know what you find! Thanks, Alana

Hi @davidroberts63 , While connector filters were never really designed to replace the "approved packages" workflow, we've seen many users do exactly that over the years, yielding hundreds of entries. It's not exactly a use case we recommend, as one of the big benefits of the approved packages flow is to prevent "instinctively upgrading dependencies" yielding in regressions. But, if you're already effectively doing that through automation, then I suppose you already know the risks :) From a performance standpoint, it shouldn't make a notable impact. Those have been optimized for quite some time now. Thanks, Alana

@atripp Thank you for your help. This resolves my problem. Good to hear that it will be default behaviour, current behaviour is not intuitive.

I actually haven't looked into pgutil yet. I'll check it out. But overall, ProGet does a pretty good job. Right now, I really can't think of anything that ProGet can solve uniquely.

No problem; I will use the generic one :) @george-bowen_9415: Did you experience delays in V5, and do you have any significant amount of group memberships? :) -Sigurd

Thank you very much.

Hi @parthu-reddy , Thanks for the additional information. Thinking about it further, I suspect this was a temporary network outage. It could have been DNS related, or who knows what. As for your configuration... 5000 is definitely too high; set this towards 100-500 max. If you're working on a load-balanced cluster, this should be done at the load balancer instead. I was incorrect about api.nuget.org, that is also used by the V3 API. I thought it was only V2. So please disregard. It's unlikely metadata caching will help, but you could try it. That's a relatively short-lived cache meant for traffic bursts, and it's not really going to help with a network outage. -- Dean

@rcpa0 thanks for letting us know; we'll try to fix this next time we make some changes to pgutil it should only print "Version is not a valid semantic version." or something

Perfect, thanks Alana :)