Hi @koksime-yap_5909 , I'm afraid we can't provide much clearer guidance than that, as there are so many factors involved that make predicting performance basically impossible. For example, the feed types you're using, your CI server configuration, how often developers are rebuilding, etc. The article you found is actually what we send users who experience symptoms of server overload, to help understand where it comes from and how to prevent it. As the article mentions, the biggest bottleneck is network traffic during peak traffic - there's only so much that a single network card can handle, and scaling CPU/RAM doesn't really help. This is where load-balancing comes in. The main downside is complexity/cost, which is why a most customers start with a single instance. It can take quite a while for a tool like ProGet to be fully onboarded across teams, so performance problems likely won't happen at first. Hope that helps, let us know if you have any other questions! Thanks, Steve

Hi @stevedennis, Thanks for the update! I’m fine with waiting for the official release.

Hi @koksime-yap_5909, The command will recreate the user, restore administrative privileges, etc. It's safe to run - and you'll ultimately be left with a Admin/Admin user that you can log-in as. On ProGet 2025, the command is proget or proget.exe We should update the docs for sure Thanks, Steve

Hi @davi-morris_9177 , For multi-file packages like PyPI, the entire package (i.e. all the files) is promoted. This is the same in the UI as well. -- Dean

@yakobseval_2238 thanks for letting us know, I just updated it!

Hi @tayl7973_1825 , Thanks for the feedback; this is all a relatively new space, so we're in the process of building best practices / advice as well as tools to help teams solve these problems. Right now, based on your suggestion, it sounds like the workflow would require us to manually identify which applications depend on a vulnerable library, notify each owning team You are correct - the SCA Builds & Projects functionality is designed to "provide that link" between specific package versions and specific builds of applications. The builds are a moving target, as they may or may not be active/deployed. The "Project" in ProGet is not intended to the "source of truth" about the project itself, but be sort of sync'd with the truth (e.g. like an Application in BuildMaster). That's why there's a "stages timeline" for builds in PRoGet. hope it fits within their priorities, and then track remediation through individual tickets. Our advice here is to think of it more like, "advise them of the identified security risk and unavailability of the impacted library they are using". Ultimately it should be up to the team (their product owner) to evaluate the risk you identified and mitigate it. For example, TeamLunchDecider1000 can probably live with a security risk, but let the team decide. Once you've removed the library from ProGet, they can't use it anymore and it's "no longer your problem" to worry about or track through tickets. Ideally, we were hoping our package management system — since it already governs distribution and security controls — could act as that “one stop shop” to track and visualize which applications still rely on a vulnerable version along side it's assigned severity rating. ProGet already provides visibility into consumers through SCA, and you can already see how OSS Vulnerabilities impact builds. HOWEVER, our core advice here is to not try to establish your own in-house "vulnerability database" for in-house libraries your organization. Even large orgs (2000+ developers) won't do that. Instead, it's a simple binary decision: PULL or KEEP the library. If you PULL, then notify consumers it's unavailable going forward and let them decide how to mitigate. That approach is superior to OSS Vulnerability workflows, but it's obviously not possible for OSS library authors to do. Cheers, Steve

Hi @andreas_9392 , That configuration is not supported and will not work; You'll need to configure https://proget.mycompany.com/ or use a port. Thanks, Alana

This would be a relatively easys change to make, but we'd like to be able to test it against a public repository that has noarch packages included in its index. The https://dl-cdn.alpinelinux.org/alpine/v3.21/main/x86_64/APKINDEX.tar.gz index file doesn't seem to have anything except x86_64 packages in it. Is there a good public repo we can use as a solid source of working example data?

@wechselberg-nisboerge_3629 great news, thanks! Well it'll be in the upcoming release (2025.13) in that case :)

Hi @Anthony , When you use SHCall, it's translated into a remote SSH command that includes all arguments inline on the shell. Basically something like ssh user@host bash -c '...' However, there is an OS-enforced limit on how long this can be, which is typically between ~32K and ~64K characters. It looks like you're there exactly, and you may be able to see this limit with getconf ARG_MAX. Note that you would also get this error if you did ssh user@host bash -c 'echo "Really long....."'. So bottom line -- this is an OS/SSH limit. To work-around it, you can just write out $arg to a file, and have your script read in that file. Thanks, Alana

Thanks for the quick response! I'm aware that I could have made sensitive information containing PID exposed to all users with access to the feed, but that is inappropriate within my organization. Best regards Nils Nilsson

Hi @mayorovp_3701 , Thanks for confirming; we can will try to get this fixed in the next maintenance release via PG-3139 -- the underlying issue is most likely a race condition on that trigger I mentioned, so we're going to fix it by adding an advisory lock. It will not remove the duplicate content, but in theory deleting the image will. Thanks, Alana

Hi Alana, thanks, great to hear you are working on this and it is also being an improvement. :) Waiting for the update then and wishing a good start into the week, Frank

@felfert I saw the set-up first-hand, though I forgot what files were being edited, a .repo file I think. But the final setup is something like... [docker-ce-stable] name=Docker CE Stable - $basearch baseurl=https://download.docker.com/linux/rhel/$releasever/$basearch/stable enabled=1 gpgcheck=1 gpgkey={put the asset download url here, e.g. https://proget/endpoints/...} ... I know basically nothing about rpm so not sure if that helps at all

Hi @pawel-ostrowski_5669, Actually the version you're using (2025.8) has a known regression relating these PackageIds that we already fixed via PG-3097. I didn't realize it until you told me the version and I found that issue. Anyway please try latest version of ProGet 2025, it should work. Thanks, Alana

ok thanks for looking in to this. fyi: I think I found out what kind of feed ist used. It seemed to be a Chocolatey Simple Server https://github.com/chocolatey-community/simple-server/tree/master So it is V2 API based, but with some chocolatey customizations. This project seems to be deprecated by the chocolatey team.

Hi @fabrice-mejean , It's no longer possible to query this information from the database. As you've noticed, ProGet now uses a version range (i.e. AffectedVersions_Text ) to determine whether a package is vulnerable or not. So instead of 4.2.3 it's now 4.2.3-4.2.8 or [4.2.*) or something like that. Unfortunately it's not practical/feasible to parse this information unless you were to rewrite a substantial amount of ecosystem-specific parsing logic - this would be basically impossible to do in a SQL query. Instead, you'll need to use the upcoming pgutil packages meatdata command to see what vulnerabilities a particular packages has. You can also use Notifiers to address newly-discovered vulnerabilities. Thanks, Alana

Hi @koksime-yap_5909 , Not necessarily - it really depends on the API query. If the query is like "give me a list of all versions of MyPackage", then ProGet will need to aggregate local packages and connector packages to produce that list. If the query is "give me the metadata for MyPackage-1.3.1", then the first source that returns a result is used. In practice, NuGet asks for "all versions" a lot. So you'll get a lot of queries. Thanks, Alana

@james-woods_8996 we haven't released the extension yet, so it won't be in any builds of the product. We are waiting on someone to test/verify that it works