hi all, thanks for the interest/comments; I decided to write-up a page that details this on the docs.

http://inedo.com/support/documentation/proget/feeds/other-types

I'm hoping we can use this public thread to maintain the discussion on technical detail; otherwise it'll get stuck in my email, or somewhere else, and we can get everyone to chime in this way.

That said, @M-W if you've got any insight into how R/CRAN works please do share :)

Of course, plan versioning is introduced in a later version, and Rafts (which allow for Git-based storage) is coming in 6.2.

I definitely understand the hesitance to upgrade, but worth noting ---- for once 6.2 comes around we'll offer some great migration tactics to let you pull applications from really old versions of BuildMaster. We'll also better support multi-instances of BuildMaster, so each group can upgrade as they'd like.

That said, the Plans database table will contain your OtterScript plans. Not sure if that's a good solution, but pulling from that table will give you latest versions.

Hello;

There may have been a miscommunication somewhere; do you know specifically what you were told?

We recently added the Feeds Management API, but that's only to manage feeds (not packages).

I just updated the documentation, and it will be published soon.

You can delete (permanently remove) or unlist (hide from most search results) NuGet packages from your feed by navigating to the package page and clicking the corresponding Delete Package or Unlist Package button. These actions require the Feeds_DeletePackage or Feeds_UnlistPackage permission attribute, respectively.

To programmatically delete a package from your feed, you can use the NuGet CLI's delete command, or make a DELETE request via HTTP:

DELETE http://{proget-server}/nuget/{feed-name}/package/{ID}/{VERSION}`

Note that this behavior is different than NuGet.org's DELETE command, which unlists packages instead.

To programmatically unlist (or relist) a package, you can use the NuGetPackagesV2_SetListed method within the Native API.

Is that helpful?

Definitely sounds like a bug; we've get it logged.

By the way, we've got some real exciting container/registry features coming very soon in ProGet 5.3. Stay tuned!

Hi @jeff-miles_5073 ,

Thanks for the first inquiry; I just updated the documentation! These must be "relatively new", and I know we've had a few customers using universal packages for this.

We have some Terraform integrations on our roadmap for 2023, so this definitely something we'll look into on our own as well.

Cheers,
Alex

Just as an update, we will be doing this:

https://inedo.myjetbrains.com/youtrack/issue/PG-1555

"Proxy npm audit requests to npmjs.org (experimental)"

Hi @shfunke_1795 , @jrottmann_6111

Thanks, I just added this to our documentation page!

I didn't look too deeply, but I found some initial documentation:
https://wiki.alpinelinux.org/wiki/Package_management

It seems this is "like Yum/RPM but for Alpine Linux"? None of us here use Alpine Linux, so there's a pretty big learning curve to get started. Any help here would be appreciated, and definitely move this along :)

Is this related to "APK" that Android uses?

Is the "API" mostly like basic file downloads, based on an index file? Are you able to "hack" or do a PoC using ProGet Asset Directories?

Hi @tkolb_7784

I wanted to provide an official answer to this:

Are there plans for (easy) HTTPS support in the internal webserver? Applying a self hosted certificate and deploying it to all build servers and developer machines seems over the top for me right now.

Yes. Not exactly sure how yet, but we would like the integrated webserver to support this as easily as possible.

@shayde @sebastian really appreciate the help, we'll get this incorporated ASAP !!

Thanks for clarifying @sebastian

So I'm not exactly thrilled by this UI, but maybe this is fine.

What do you think?

This is a kind of "quick and dirty" page that would show up if you clicked on that GPL-2.0 license and the "# projects" number.

Here's one for the packages as well:

Hi @paul-moors_5682 ,

We'll definitely keep an eye on this after ProGet 2026; we're doing some big improvements for vulnerability management, which will probably push more folks out of the Approval Workflow.

One thing I like about an in-built workflow is that it demos really well and makes it so much easier to see/understand how an approval workflow could work. While I personally love the idea of "approved packages only", it's so hard to recommend that workflow in practice.

Anyway, let us know how your approval-only journey goes. We tried it internally here and it was a flop... just Microsoft's growing dotnet dependencies alone made it impractical.

Cheers,
Alex

Hi @paul-moors_5682 ,

Thanks for sharing this idea; it's interesting idea and is actually something we talked about internally over the years.

However, after several conversations with a few customers who used the Package Promotion Workflow, they wouldn't find any value or use the feature. The reason is, they already have workflow tools (ServiceNow, JIRA) that document/automate SOP like these, and some will even do a quick API call once the package is approved.

In other words, everything happens in the workflow tool -- which is used for every other SOP from architecture review to vacation requests.

Now just to comment on the "best practices" part; we are working on revising our practices, but we don't consider "package promotion" the best practice anymore. Instead, we consider it the "option with the most control (and highest cost)".

If that level of control is not needed by the organization, then it shouldn't be used -- given the explosion of dependencies (1000+ for the average npm project), it's a lot of process to maintain. A lot of customers (military contractors, etc) are used to that level of process/control and it's fine.

But if you try to institute this at an organization without this process-heavy culture, you'll get a "rebellion" and just see shadow-IT and bypassing of these rules. And they won't get fired or even scolded.

And that brings us back to why no one seems to want this type of system -- companies with this level of process use ServiceNow/JIRA for everything already.

Cheers,
Alex

Hi @davidroberts63 and @mikael ,

Thanks for the insight and ideas!

I'm surprised to hear that a "proxied" Terraform Provider Registry wouldn't be a security concern; it seems like a great vector for a trojan-horse provider reference (say aws-core) to be snuck into some proxied module dependency and auto-downloaded and run?

Of course I know nothing about how Terraform actually works... or if that attack would be possible. Realistically, someone would probably catch/report it shortly after discovery... but "proxying executables from community repositories" raises a big red flag for me.

Anyway, it'd be a lot of effort to build this into ProGet and I don't think we can really offer any value over a specialized basic free/open source tool that hosts these providers. Ultimately it'd be like an Asset directory, but slightly more restrictive and with an even worse UI ;)

I think if we're going to consider specialized feeds to host "non-package" files, we should probably start with like Git LFS... then Git repositories, and so on.

Anyway keep us posted on the journey; I'm sure this is one of those things you could built-out in an Asset Directory using pgutil and a ChatGPT-generated script to generate the index file.

Cheers,
Alex

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 @fbiryukov_8162,

I did a quick read of the content, and based on this statement ...

"Private Marketplace is available to GitHub Enterprise customers. VS Code users must sign in with a GitHub Enterprise or Copilot Business or Enterprise account to access." sounds to me like a closed ecosystem

And these technical instructions ...

https://github.com/microsoft/vsmarketplace/blob/main/privatemarketplace/latest/README.md#5-connect-vs-code-to-the-private-marketplace

... this is a locked-down / closed ecosystem. There's no published API/specs and no still no support in VSCode for private galleries. They're just "hacking" internal settings to get VSCode to use a different service URL, which they also control.

Obviously this is not something we could/would want to reverse engineer and then support.

If the VSCode team adds support for private repository/galleries (and a public/documented API), and there's some degree of stability to that, we'll consider it. But until then, not much we can do.

Best,
Alex

Hi @dubrsl_1715

I was sure that you must be interested in creating a product that would solve real tasks.

Not really :)

As a products company, we solve problems that a sufficient number of users would be willing to pay for and that aligns with our overall strategic vision.

We also do User-Driven Development, which means we prioritize helping our existing users/customers solve problems instead of adapting the product for nonusers/evaluators like you guys.

We don't consider packagist a competitor nor are we currently marketing users to switich; our solution is similar but not an analog. It requires a change to your workflow.

The PHP/Composer market is already hyper-niche and I'm not convinced there's enough demand to develop a "versionless" package format (i.e. where a version number cannot be discovered in the manifest file or the package file name) format just for this particular use case (i.e. alternate workflow / simpler migration from packagist).

None of the other feed types have this requirement, and it'd be nontrivial to modify our model to support this unique requirement. It would have downstream impacts to features like replication, disk-importing, reindexing, etc.

Thanks,

Alex

Hi @dubrsl_1715 ,

I don't think ProGet is the right solution for you guys. Supply Chain Security and OSS Governance are clearly not concerns, and you're simply not going to get any real value out of a product designed to help organizations solve those problems at the cost of convenience.

I think you will be much better served with the free/OSS repositories for your various repositories; we call that Level 2 in Package Maturity, and I can't imagine any of the "pain points" articulated in that article will resonate.

There's nothing wrong with that. As I've always said, sometimes a Source Control Shingle is the right tool for the job.

Best,
Alex

@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 @fhusson_1634 ,

From a quick read of the documentation, it looks like an "MCP Registry" is basically a list of "MCP Servers", which is basically a JSON document that describes.... an API or something?

What I'm not seeing are "Packages" (i.e. an archive file with a manifest file) nor a "Central Repository" (i.e. a canonical location where OSS Models are stored). If that's the case, I'll do a "hard pass" on this for the forseeable future -- there's not much value ProGet could add here and we'd have to add a completely separate, non-package subsystem like Assets or Docker.

Let me know if I misread the specs

Thanks,
Alex

@sebastien-gamby_3349 check with the VSCode team.

They first need to implement support for private repository/galleries, and then we'd need to see some level of stability before considering it.