Hello; I've updated the documentation to clarify this, but it's available starting in ProGet 5.2.9. So, you'll need to upgrade to enable it :)

Thanks for the update! I've noted this in the docs, and linked to this discussion :)

https://github.com/Inedo/inedo-docs/commit/d24087911584bbda833314084a58c2ae1ff41c39

Hello,

That API will only delete package metadata from the database, not from disk. It's mostly intended for internal use only, and probably shouldn't be exposed to the API. In any case, we don't store the @ with internally, so if you change @myscope to myscope it should work.

Note that the NPM doesn't provide a way to delete packages, and we never implemented it. There hasn't been any demand for it to date, as people don't really delete packages programmatically - but you're definitely welcome to submit a feature request and help us understand why it'd be a value (like, the workflow you use that requires deleting packages, etc).

Alana

Hello, for sure!

It's pretty easy; just don't give the Anonymous user any access to your feeds, and then authentication will always be required, either when browsing the ProGet application or using the API (such as Install-Module).

When you use the Register-PSRepository command, you can the Credential option to specify a credential.

This credential can be the name/password of a user inside of ProGet (let's say, Admin:Admin), or it can be username of api with a password of an api key you've configured (so, api:my-secret-key).

Hello;

The Native API is for low, system-level functions, and it's "all or nothing". If you give someone access to Native API, you are effectively making them an administrator, as they can also change permissions and grant admin privileges. So, I don't think you want this. Instead, you'll want to use the Debian API endpoint that we implement.

It's a third-party API format

In order to support third-party package formats types like NuGet, npm, etc., ProGet implements a variety of third-party APIs. We only provide minimal documentation for these APIs, as they are generally either already documented elsewhere. However, you can generally find the basics by searching for specific things you'd like to do with the API, such as "how to search for packages using the NuGet API" or "how to publish an npm package using the API".

So in this case, I recommend to search "how to view and download apt packages".

I'm not very familiar with PyPi packages, but I know there are some oddities with - and _, and that they are sometimes supposed to be treated the same, and sometimes not. We don't totally understand all the rules, to be honest (even after reading PEP503 specifications).

In this case, the package is actually websocket_client, not websocket-client.

See: https://pypi.org/project/websocket_client/

When you search for websocket_client in ProGet, it shows up, as expected.

In ProGet 5.3, we plan to have a couple tabs on each Tag (i.e. container image) that would provide this info: Metadata (will be a key/value pair of a bunch of stuff), and Layers will show details about each of these layers.

That might help, but otherwise, we have retention policies which are designed to clean up old and unused images.We'll also have a way to detect which images are actually being used :)

As @apxltd mentioned, we've got a whole bunch planned for ProGet 5.3.

I've logged this to our internal project document, and if it's easy to implement in ProGet 5.2 (I can't imagine it wouldn't be), we'll log it as a bug and ship in a maintence release.

Do note, this is not an IMAGE description, it's a REPOSITORY (i.e. a collection of images with the same name, like MyCoolContainerApp) description; so this means the description will be there on all images/tags in the repository.

You're right, I guess that's showing the "layers" instead of the "tags"; I think it should be showing container registries separately (they're not really feeds), but that's how it's represented behind the scenes now.

Anyways we are working on ProGet 5.3 now; there's a whole bunch of container improvements coming, so I've noted this on our internal project document, to make sure we get a better display for container registries.

@Stephen-Schaff thanks for the bug report, I verified that this may happen depending on permission of user, and which feeds they can/can't use --- but it seems an easy enough fix that we can do via PG-1894 (targeted to next release) - the packages can't be viewed upon clicking, but it's a sub-optimal experience for showing packages they can't see

Hi @daniel-mccoy_4395,

Based on what you've described, it sounds like ProGet is indeed blocking downloads; this is visible in the ProGet Web UI with a "Download Blocked" indicator. If you try accessing the download URL, you will in fact get a 400 error.

However, NuGet/Visual Studio aggressively cache package - which means they aren't even attempting to download them. If you clear all the NuGet caches (system, user, http, project, etc), then it should attempt to download then again.

That said, as of ProGet 2026, we no longer recommend downloads. This is one reason, but there are more reasons.

Here's an work-in-progress article that discusses our new guidance:
https://guides.inedo.com/vulnerability-management/containment/

Cheers,
Alana

Hi @carl-westman_8110 ,

Not really... Feeds and Views are a bit different concept and we don't really encourage using the presence in a particular feed as a means to identify whether something has been released. Instead, we'd encourage using Pre-Release Packages & Repackaging
, which make it obvious from simply lookin at the version (i.e. 1.1.1-rc.7 indicates not yet released).

Thanks,
Alana

Hi @certificatemanager_4002 ,

ProGet is licensed per instance (i.e. installation), you will need a separate license if you wish to maintain a production and non-production instances of ProGet. See the official Licenses for Non-production / Testing Environments for more details.

For things like a one-off, cloud-migration, using a Trial license (which you can get from My.Inedo.com) is fine.

Thanks,
Alana

Hi @certificatemanager_4002 ,

Just to clarify the support:

We are planning to upgrade to ProGet 25.x, as we understand that Microsoft SQL Server support will be not supported by the end of the year.

We are currently planning to discontinue SQL Server support in ProGet 2027. It will continue to work in ProGet 2025 and ProGet 2026 regardless of when you use the software.

To answer your questions...

1. You can continue using SQL Server in ProGet 2025
2. Please see Configuring High Availability & Load Balancing, which details the implementation
3. ProGet for Linux is supported in a Docker environment; many users will deploy using Kubernetes, but we do not provide charts or templates... only a Docker Installation Guide that you will need to "translate" into pods, etc
4. ProGet can handle that traffic, though a lot of factors will determine how much server resources are required; I would start with a two-node cluster and evaluate/consider adding more if needed

Thanks,
Alana

Hi @Ashley ,

Good news -- this will be fixed via PG-3265 in the upcoming maintenance release (next Friday).

In case you're curious, the bug was that we were comparing packagePublished.AddDays(recentlyPublishedDays.Value) > DateTime.UtcNow.Date, which includes the time-portion on the left side, but not the right-side (so 12:00A).

Just changing to packagePublished.Date.AddDays(recentlyPublishedDays.Value) > DateTime.UtcNow.Date does the trick, and it works for both Aged and Recently Published.

cheers,
Alana

Hi @stno_9153 ,

Thanks for clarifying; that's not possible with ProGet. A Debian feed is not designed to be a "read-only mirror", but instead a repository where you can add/filter/update packages. So, that's why ProGet must generate/sign the (In)Release files.

I'm afraid we have no plans to support a read-only mirror use case in the forseeable future.

Cheers,
Alana

Hi @stno_9153 ,

(In)Release files are signed using a private/public key scheme, so unless you were somehow able to get a copy of Ubuntu's private signing keys and upload it to ProGet... it is not possible to sign those files using the original Ubuntu Key.

Cheers,
Alana

Thanks @Ashley, that's exactly what I was thinking.

I haven't tried reproducing this yet, but I've got all the steps to now! And at that point, I'll have a debugger and all the code in front of me, so it should be an easy fix. It's probably related to UTC/local time, I don't think we've ever tested it "by the hour" like that :)

Anyway stay tuned we'll get it fixed pretty soon.

Hi @stno_9153 ,

Oh yeah, that'll make a HUGE difference for public repositories. OTherwise it'll probably not work at all :)

Anyway glad it's working now

Thanks,
Alana

Hi @Ashley ,

To set override the publish date, first Pull the package to ProGet so that it's no longer a cached package. Once you do that, you will see a "Set Package Status" option (you may need to refresh page). On that modal dialog, select "Override Metadata..." and enter the date.

That's what we do to test these rules; note you can delete the package and re-download it to cache it again.

Let me know if you spot anything off, it seemed to work for me, but I might be looking at the wrong things.

Thanks,
Alana