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

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

@stevedennis sounds perfect, thanks Steve! :)

@dean-houston Interestingly, this issue is not happening now. After the update to the latest version it was happening, but then I restarted the server BuildMaster is on (unrelated, needed Windows Updates), it has seemingly resolved itself. So I guess this can be closed?

Hi @bobmaurer , We recommend to import those packages into ProGet and publish to ProGet going forward. That keeps ProGet as the source of truth for your artifacts, reduces a lot of network traffic, makes it easier for developers to not worry about multiple sources, and eliminates a lot of possible headaches later with configuration/outages/authentication./etc. Much simpler this way. Best, Alana

Hi @rhessinger, I have now tested 26.0.9-ci.1 in a test instance and I can confirm it is working exactly as expected. Thanks for the quick response again! Joris

Hi @dean-houston, I think there might be a little bit of a misunderstanding. I'm not really evaluating the product. I'm selling the product. I've been using BuildMaster for over 10 years (I'm thinking 14 or 15) and most of which as a paying customer. I started a new job last year and I'm once again I've decided to try to sell your product to my employer. Previously I've just had to do a presentation on the product to get the company on board. Here, unfortunately, I need to do a little more show-n-tell rather than talk about the product. Not only that but this is the first place I've worked at that has a workflow quite like it does so it has brought up questions I didn't have to deal with, but I've never had any doubt I could/would accomplish what I needed. Since I know how hard of a sell this will be I'm trying to put extra effort in to coming up with the best demo possible and is leading to some of the questions. Thankfully I think I'm near the end of building what I need to build so hopefully will not be doing too many more posts on the forum. I really do appreciate all the time you and others have given to respond to my posts but I do feel a bit bad for how many and how complex my posts of been. Unfortunately I do not really know when I'll finally do the demo/presentation to my superiors, and I am kind of hoping I can wait until 2026 comes out before I do. I hate to sell a product and the version my pitch is based on is no longer the newest :-). Thank you, Brandon

Thanks @sigurd.hansen_7559 ! All right, I'm convinced.... this makes a lot more sense now to do now! I didn't quite realize that Microsoft does not allow non-VSCode clients to connect to their Marketplace, nor did I realize there were so many VSCode forks. The current plan is to create a new feed type called "Open VSIX" or something that will support connectors. It should also be able to handle the "multi-file packages" (i.e. how the same extension can have multiple .vsix files but different architectures). We should be able to just reverse engineer the VSIX API as well. That's clearly Open VSIX did; it's not all that complex I think. I've just now updated the other feed types; we don't have a date just yet, but it should e in the coming months. We'll keep this thread up to date.