Hi @sigurd-hansen_7559 , Thanks for pointing me to the repository; I was able to reproduce this, and it will be fixed via PG-3194 in the next maintenance release (scheduled for Friday). Thanks, Steve

Hi @toseb82171_2602, In Docker, images must have a namespace. When they don't, the Docker client will transparently append library/ to those namespaces. In general, this behavior is not desirable, and it's recommended to use library/python or, in a ProGet context, myproget.corp/mydockerfeed/library/python. That said, there is a setting on the connector that may help resolves such images, but these images can be problematic even with that. AS for extending the trial, no problem - you can actually do this yourself on my.inedo.com, on the day of expiry. Of course, please contact us if you run into any issues or have licensing questions. Thanks, Steve

Hi @jeff-williams_1864 , We do not provide instructions/guidance for installing ProGet on Kubernetes / OpenShift. However, since it uses Docker behind the scenes, it is supported and works fine, and many users deploy ProGet to Kubernetes. Here are the instructions for Docker: https://docs.inedo.com/docs/installation/linux/docker-guide Let us knkow if you have any questions or run into any issues/difficulties. Thanks, Alana

Hi @nachtmahr, Yes, that's what I would reommend doing -- using the internal storage path. Just make sure to NOT select the option to delete the files and make sure to select "search subdirectories" so everything will be imported. Cheers, Steve

Hi @henderkes, No problem! Both these issues are expected to be fixed in this Friday's release of ProGet 2025.18. Thanks, Rich

Hi @tyan-yin_2201, It looks like it's only supported on FeedCommand -- I'm not entirely sure why. It appears to be settable when calling the HTTP API however. We ought to be able to add it relatively easy, but can you share the use case? It's also good to know why someone would want to explicitly set an api key from command line (most tools don't seem to support this). -- Dean

@dean-houston hi, problem fixed. thank you

Hi @mayorovp_3701, This is a bug you should definitely report to GitLab -- it's clearly required by the API and all other registries support it. Without that API defined, we have to "make guesses" based on undocumented conventions (i.e. /v3-flatcontainer/{id}), which causes headaches down the line. That's why there's an API contract :) I don't know how/why it works with dotnet sdk -- perhaps it's using a different endpoint, or maybe it's not actually working and just going to NuGet.org. Whatever the case, it doesn't make sense for us to build workarounds for easily-fixable bugs on GitLab when other vendors seem to follow the API contract. -- Dean

@jonathan-werder_8656 great point, we'll add that to our list to document! Thanks for pointing it out

Thanks! This will be fixed in today's release of ProGet 2025.17 as PG-3187.

Hi @MellowOak, A quick background on how ProGet handles malicious packages. Malicious packages are treated as vulnerabilities in ProGet. That means that a malicious package will show up as an unassessed vulnerability (since they rarely have a CVSS score) and can be assessed, analyzed, and blocked like any other package with a vulnerability. With that said, most of the time, this blocking is not needed because as soon as they are identified as a malicious package, the public feed will have already removed the package. The only time they are really caught in ProGet is when they have already been downloaded and cached. In ProGet 2026, we are working on a better way to store and distinguish malicious packages separate from vulnerabilities. To answer your questions: All paid editions support the ability to block malicious packages via policies. Please refer to our License Restrictions documentation for edition limitations. The best configuration for blocking malicious packages is to block all unassessed vulnerabilities. This requires an administrator to review unassessed vulnerabilities regularly on the Reporting & SCA -> Vulnerabilities tab. Yes a block can be overriden by: Add an exception in the policy for that package and version A ProGet admin can set the package status to Always Allow It could be manually downloaded from the ProGet UI Inedo's aggregator runs mutliple times a day to pull from all the vulnerability and malicious package sources and creates a custom compresssed database file. As long as ProGet has access to cdn.inedo.com, ProGet will then download that file nightly update it's database. It can be updated under Scheduled Jobs -> Vulnerability Database Updater. There are multiple ways to gain visibility, but the easiest is to use ProGet's notifier feature to be alerted when a vulnerability to a pacakge. Hope that helps to answer your questions! Please let us know if you have any other questions. Thanks, Dan

Module streams are a little complicated for package maintainers, because the metadata has to stuff certain packages (all from the same folder) in one stream while others in the other. The end result is really nice though, because it makes switching versions of packages trivial. Sounds like it's not supported then. Unfortunate, but understandable.

Hi @koksime-yap_5909 , As long as the cluster can access the internet (our activation server), the license key should be auto-activated without noticing. This document explains the activation process a little further: https://docs.inedo.com/docs/myinedo/activating-a-license-key Help that helps, Alana

Thanks for the additional feedback @ben_0435 Mostly for my notes, in the five months since @Jonathan-Engstrom shared Microsoft's initial efforts at supporting a WinGet private repository (i,e. winget-cli-restsource), it looks like they've already abandoned their efforts. Last code commit June 26, 2025 Last closed issue July 4, 2025 So at this point, my assessment remans the same: WinGet is basically just the Windows Store, except you it run from the Commandline and has a ton of shady, unvetted packages from internet randos I feel someone should totally Polymarket whether Microsoft will finish WinGet --or-- just create yet another package manager that's somehow more BingAI friendly. I'm looking for a solution to titrate that scary giant community repo so it can be managed better... I want upstream.. but only select things. I want to publish apps as necessary for the public/private feed. I believe that solution is called "Chocolatey"

Hi @rhessinger, I just tested the pre-release and the build now works as expected. Thanks again for the quick fix!

Hi @atripp Once again thanks for the quick fix. I was actually worried that something got messed up in our database, while trying to fix the duplicate package issues, but so far everything looks good. Also I should probably start making it a habit of stating that we're still on SQL Server, instead of having you guess. ;)

@kinedax339_3276 great news!! Appreciate the help