Hi @certificatemanager_4002 , Maybe you're attempting to delete a principal that's not a user, such as a group or Anonymous or something. In any case, the API uses the exact same code as the UI; I'll share it: case "delete": EnsureMethod(context, "POST", "DELETE"); var userName = context.Request.QueryString["user"]; if (string.IsNullOrEmpty(userName)) throw new HttpException(400, "Expected user query argument."); DB.Users_DeleteUser(userName); break; Here is the UI code for the button click on the /administration/security/users/delete-user?userName=asdfasdf page: var btnDelete = new PostBackButtonLink( "Yes, Delete User", () => { DB.Users_DeleteUser(this.UserName); WebUserContext.ClearCache(); this.CloseModalWindow(false); } ); Your request might not be reaching the endpoint; I would attempt to do DELETE /api/security/users/delete?something=nothing to make sure you're getting a 400 error. Hope that helps. Alana

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

Hi @dbojak , We do User-driven Development, so this is something we could work on after customer onboarding. The audit changes you describe seem reasonable, although we would obviously need to work together to translate that to product-specific terms; e.g. there are no "feed security policies", just scoped privilege/restrictions that associate a principal with a task, and those are either are added/deleted. You'll understand these as you learn our product a bit more, however. And obviously there are also some technical limitations far beyond ProGet - for example, knowing which user downloaded a package requires that user first authenticating to the feed. Otherwise these kind of changes are relatively easy to implement and something we can often add in maintenance releases. However, it's unlikely we will add SIEM integration as a feature; it'd be a substantial undertaking that is like 95% outside of ProGet's core functionality, and would require continuously supporting third-party log aggregation platforms we have zero exposure to. We would need to see (1) a lot more demand, and (2) user-created prototypes that extract/convert from the database. A handful of users have written "log exporters" to tools like Splunk, but they are so highly specific to their requirements that it would be impossible to generalize as an open-source tool, let alone a product feature. Thanks, Steve

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 @atripp, Tested in our dev instance and seems to be working ok now, thanks!

Hi @atripp Thank you very much for your feedback and support. Best regards

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

Hi @joris.guex You're right! It looks like ProGet is reporting the second value of the range as if it was an exclusive bound rather than inclusive. Somehow it has been like this for years. Anyway, it looks to be a trivial fix, so we should be able to get this in this Friday's release of 2026.9. I've created PG-3350 as the tracking issue for it. Thanks for reporting the problem! -Greg

@stevedennis sounds perfect, thanks Steve! :)

Hi @amy.j , If the package is already cached in ProGet, then the publish date is already set. So, i would make sure to delete the package and try it again. Otherwise, can you share more specifics? That way we can create a reproduction case. Thanks, Alana

@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?