Crazy ... and this issue is still open https://gitlab.com/gitlab-org/gitlab/-/work_items/588736 That way the combination is not usable... I really wonder how the build in dotnet nuget tooling is working with the group feed.

Hi, we also check for package compliance in our promotion pipeline, using the metadata API, and generate a summary based on that data. Just wondering if the API behaviour has changed? The ProGet version is: 2026.10. For example, one of the dependency packages that was flagged was: charset_normalizer/3.5.1. This particular version was showing as non-compliant (based on our policies), as no license was detected. Double checking, from the UI in the related feed, the package is showing as compliant and has a license assigned. From the UI, we selected the 'Reanalyze Package' option (even though we weren't aware of any changes), however the API is still reporting the package as non-compliant. Below is the response for the specific package: { "analysisDate": "2026-09-14T09:31:37.1628362Z", "analysisResult": "Warn", "issues": [ " No license detected", " No license detected", " No license detected", " No license detected", " No license detected", " No license detected", " No license detected", " No license detected", " No license detected", " No license detected", " No license detected", " No license detected", " No license detected", " No license detected", " No license detected", " No license detected", " No license detected", " No license detected", " No license detected", " No license detected", " No license detected", " No license detected", " No license detected", " No license detected" ] }

Hey there, very nice to see this topic discussed here. Just my two cents: I'm running Grafana Alloy as a sidecar container, exporting the ProGet console output and the Nginx logs to a central Grafana instance. This gives me some visibility into how the application is running. Exporting the Logs from the database table via OpenTelemetry to some SIEM would be very nice too.

@atripp award for fastest forum response goes to you yep that seems to have solved it :) simple enough ;) Thanks! Maybe it would be an idea to highlight or add a little orange "stalled" badge on the ones in the list that causes the warning? Just a nice to have. Cheers Carl

Hi @certificatemanager_4002 , The API is a bit harder to use than just pgutil, so I'd suggest to use pgutil instead and it's easy to make a simple mistake like encoding something incorrectly. Without studying your code and having direct access to your ProGet instance, I cannot tell you what the issue is. But, since pgutil works we know the API is fine; here is the code that pgutil uses to delete the user: https://github.com/Inedo/pgutil/blob/thousand/Inedo.ProGet/ProGetClient.cs#L744 would suggest to use a local proxy tool like fiddler classic, proxyamn, postman, etc., that can capture and analyze local HTTP traffic so you can see the difference between what your code is doing and what pgutil is doing. Thanks, Alana

Hi @gdivis, Thank you, I can confirm that the case with a partially downloaded file now returns the correct Content-Range header as expected. However, when a file is fully downloaded, it still returns an Invalid Content-Range header: $ wget --server-response --continue --tries 1 https://<PROGET_URL>/endpoints/assets/content/example_file ... HTTP/1.1 206 Partial Content Content-Range: bytes: 1000-999/1000 ... Giving up. I know this is a bit of an edge case, as usually you don't try to continue downloading a file that is already fully downloaded. However it does happen in specific cases with bitbake so it would be good to get this case fixed as well. Thanks, Joris

Hi @rob , When using the the subject name, the X509NameType.SimpleName is extracted and compared. Here's the specific logic: x509Store.Certificates.Where(c => c.GetNameInfo(X509NameType.SimpleName, false).Equals(config.Subject, StringComparison.OrdinalIgnoreCase)).OrderByDescending(c => c.NotAfter).FirstOrDefault() So if the "wrong" Server1 is being selected, I'm guessing it shares the same simple name. In scenarios like this, we recommend renaming the certificate (e.g. ProGetSsl), using a file, or the thumbprint. Thanks, Alana

Hi @gdivis Thank you so much for your support. Best regards

Hi @nils-nilsson, We've investigated and this is definitely a bug in the feed management API. Unfortunately that API is pretty rough, and this is not at all the trivial fix it ought to be. I've logged the issue as PG-3369 and scheduled it for ProGet 2026.12, which is the release after next, currently targeted for Oct 2. -Greg

Hi @federico.conoscenti , Universal Package do support arbitrary metadata in the manifest file, and ProGet will display that on the UI. It's technically possible to add arbitrary metadata to other package files as well, although obviously ProGet could never know about or display that. However this metadata is not intended for searching or indexing. ProGet does not support "arbitrary, server-side metadata" for any package types. In other words, you cannot simply "tag" or "annotate" otherwise packages after they've been added to ProGet. This is intentional and by design, as it keeps the metadata contained to the manifest file (which is stored within the package file itself), which effectively makes it "cryptographically sealed" and cannot be tampered with. So, as you migrate from Artifactory, you'll need to change your workflows to support a more modern, package mindset. In case you haven't seen it already, we have a Migrating from Artifactory to ProGet Guide that you may find helpful. Best, Alana

Hi @seanl_4808 , First and foremost, we recommend that you move away from Windows Integrated Authentication as Microsoft is discontinuing the technology and move to a modern, more secure technology. It's only going to be a matter of time before WIA stops working altogether due to bugs or removal of support by us or Microsoft. That said, WIA is pretty limited as you can see. However, you can try configuring IIS as a reverse proxy that forwards https://hostname:443 to http/:*:8624; that may also make certificate management easier. We don't have a guide to set that up, however; I'v eonly heard of one customer who made it work somehow with WIA. Thanks, Alana

Thanks for the feedback @lukas.christel_6718 In the year and a half since my last rant, it doesn't look like the state of OCI Registries has changed much. I haven't been seeing any real adoption beyond some quirky or niche uses cases like Flux, due to all the reasons I mentioned earlier. It's a terrible repository format. That said, S3 (or the API I should say) seems to have become a kind of standard, and we're seeing a lot of users switch to S3 alternatives that use the S3 API: https://blog.inedo.com/proget/s3-alternatives For example, we've switched to Wasabi and have saved a ton in egress fees. You should probably have some kind of S3-esque thing in your organization already -- and if not, you should set one up. ProGet Asset Directories are convenient, but they aren't designed to solve the same problems as cloud-like storage. Cheers, Alex

Hi @fhusson_1634 (and cc/ @dan.brown_0128), We conducted some research into MCP Servers and MCP Registries (or "Metaregistries" as they are technically called). However, based that, it doesn't make sense for us to pursue at this time or likely in the future. I'll share my (new) understanding; I don't think MCP Registries will be a thing a year or two from now. First issues comes down to quality. If you take a look at the Official MCP Registry, you'll see it's almost entirely just a bunch of AI-generated MCP Servers published by vibe coders. This one kid basically spammed the MCP Registry with hundreds of named-mcp-utilities, which appear to be like leftpad but for slop coding. There's just no sense in even attempting to curate MCP Servers from this mess - it's 99% rubbish on a good day. So best case scenario... you would have to point to a private MCP Registry, which are far and few between. The major AI tools (Claude, etc) just use a curated list of plugins that do the same thing. Second issue comes down to instability. The MCP Registry protocol has been changing quite a bit and isn't remotely stable enough to reliability aggregate or curate. Since AI agents are what's "talking" to an MCP registry, the protocol doesn't reaaaaaaaly need to be API-stable. Finally, it's pretty much obsolete already. The "old" (i.e. few months ago) way of communicating with MCP Servers was using a streamable-http interface, where your LLM and the MCP server "chatted" over a quasi-API. But now it's done through "MCP Server" packages. These days, your LLM agent now just "chats" using some specially-built npm or pypi MCP package. There are a ton available, just search "mcp" on npmjs.org for example. The LLM basically just downloads/runs these packages in a sandbox scripting environment, and the package then forwards that to a real API somewhere. ProGet already supports "MCP" packages. They are just regular npm/pypi packages. And, it turns out... the AI coding tools (Claude et al) already support private package registries. And that's exactly how a lot of our users have been working with ProGet for their AI-assisted teams. They curate these mcp packages just like they would any other. The future will probably just be packages. I have no idea if MCP will even be a thing in the future. It's just a "quasi API for LLMs". But it's clear that it's heading towards packages already, and I imagine that some ecosystems may add additional metadata inside packages to give the LLM usage instructions. Who knows. Best, Alex

Hi @msicc , Great question; so it's the same product/software (ProGet Enterprise), just with different packaging/quantity: Essentials consists of a single license of ProGet Enterprise Complete consists of two licenses of ProGet Enterprise plus Services It's not uncommon to have multiple licenses for non-production scenarios: https://docs.inedo.com/docs/proget/administration/license#licenses-for-non-production-testing-environments Licensing is per instance, which can be a single-server installation or a clustered (multi-server) installation. -- Dean

@dean-houston Oh, you are totally right. I didn't notice. Thank you so much, sorry for the trouble. Kind regards.

I think adding a yanked flag is a good approach when it comes to PyPI. It is how packages are "deleted" from that index anyway, and package managers do have to deal with that on a regular basis. I'm happy to give that a try on our end. I think purely for the "let's not show the users packages newer than x days", newer packages could also be entirely omitted. This should not break anything if it was applied this way: Stop showing packages newer than the moment the policy is enabled. Wait x amount of days. Start showing packages uploaded x days after the moment the policy was enabled. Essentially ProGet would delay everything it pulls in from PyPI. Maybe that could be an option on the connector. This doesn't work for "noncompliance" in general, and I don't know how well it translates to other package indices.

Hi @hardik.turakhia, When you say external (org) PostgreSQL database, are you referring to a PostgreSQL database you are already hosting in your network and the one that is in the docker compose was for testing? Or are you just trying to host PostgreSQL in a separate container than ProGet, but both controlled by that single Docker compose file? If you are not using HA/Load Balancing, we recommend using the Embedded database. In a HA/Load Balancing environment, we recommend using InedoDB. If you are still planning to use an external PostgreSQL database (InedoDB or PostgreSQL directly), here are some things to get you started. First, only InedoDB or ProstgreSQL 17 is supported. With that said, your ProGet service in your compose file is not quite right. You have duplicate volumes and your environment variables are using unsupported keys. A good starting point for you should be to review our Docker Compose guide and our Docker guide. Based on that, here is a better ProGet service node that can get you started. pg: image: proget.inedo.com/productimages/inedo/proget:26.0.9 container_name: proget restart: unless-stopped ports: - "8624:80" volumes: - ./proget-packages:/var/proget/packages networks: - proget environment: - PROGET_POSTGRES_CONNECTION_STRING: Server=postgres;Port=5432;Database=proget;Password=Pass@123;Username=root; - PROGET_ENCRYPTION_KEY: ${ENC_KEY} I removed the volumes for database and backups since you are planning to use an external database. I'm also using ./proget-packages/ for the volume mount. You had duplicates specified in your volume mounts, so update that path if you want to store it elsewhere. Then you need to specify the connection string for your PostgreSQL database in the PROGET_POSTGRES_CONNECTION_STRING environment variable. Lastly, I added the encryption key environment variable. You can generate this initially using head -c16 /dev/urandom | xxd -p -c32, then you will want to make sure you do not change it going forward. That should be enough to get you up and running. For other volumes you might want to use see our other volumes section in our Docker guide. For other supported environment variables, see our supported environment variables section in our Docker guide. Thanks, Rich

Hi @stevedennis, thank you very much for your reply Caterina

Hi @amy.j , The URL doesn't appear to be a valid Debian repository. Navigating to the root gives an AccessDenied error. In a normal repository, there is usually a kind of file list/system. But that's not required. The root of a Debian repository has a dists folder, and then a folder for each contained distro, and a Release index file. I tried to navigate to $ROOT_URL/dists/trixie/Release but received the same error message. I also tried stable, but it didn't work. Maybe there's a dist that will work, but I don't know what it would be. Thanks, Steve