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 @aleksander-szczepanek_3253 ,

If you navigate to Admin > Advanced Settings and check "Use Connector Publish Date", then this will behave as you expect. Note that you will need to delete already-cached packages.

This will be default behavior in ProGet 2026+

Cheers,
Alana

Hi @denis-krienbuehl_4885 ,

Thanks for checking; for a short-term like this no problem!

Cheers,
Alana

Hi @EnterpriseVirtualization_2441 ,

We do not recommend using SQL Server Availability groups..

For a product like ProGet, a single database node is all that's required -- and it's strongly recommended.

There is no practical benefit to a clustered database here - on the contrary, it makes the product slower, less stable, and more costly/complex to maintain. As such, InedoDB does not support clustering.

Cheers,
Alana

Hi @jeff-williams_1864 ,

ProGet for Linux (Docker) is fully supported. You deploy it how you'd like, and many customers use container orchestration platforms like Kubernetes with no problem.

However, we only provide step-by-step instructions for Docker. This is intentional, as these platforms are quite complex and require a lot of skills to configure, maintain, and troubleshoot.

While we try to help support "platform issues" on Windows (i.e. everything from permissions to Domain configuration), that's a lot more straightforward for us to support -- and Microsoft can pick up the slack (e.g. a failed Windows update, etc).

So long story short, if you are comfortable with Kubernetes/Openshift, feel free to use it. But otherwise, we don't want ProGet to be our users' "first Kubernetes" experience :)

Thanks,
Alana

Thanks for pointing that out @rcpa0 ! I've just updated the docs now.

Hi @jeff-williams_1864 ,

You mentioned that you're "using the embedded database at the moment", which I take to mean that you're not using a separate SQL Server container image.

The In that case, the only options for a clustered installation is using InedoDB (recommended) or an External PostgreSQL (not recommended).

If you were using SQL Server, then SQL Server would be supported for a clustered instance as well. However, we are moving away from SQL Server, so we definitely wouldn't recommend it on a new installation.

Thanks,
Alana

Hi @devops-user @joshua-mitchell_8090 ,

Thank you so much for testing! We'll merge this in via PG-3251 in tomorrow's maintenance release.

As for the other error, it's technically unrelated - but that package has such a long "compliance analysis report" that it's getting truncated in the database cache. PostgreSQL complains about that, SQL Server silently does it. Anyway w'ell fix via PG-3250 perhaps in tomorrow's release as well.

Cheers,
Alana

Hi @Stephen-Schaff ,

The Docker API does not use API keys but a ticket-based system (i.e. docker login). Here is how to use it:
https://docs.inedo.com/docs/proget/docker/semantic-versioning#example-powershell-script-to-authenticate-to-docker

We added some kind of support via PG-3206 in ProGet 2025.20, though it was only intended to address self-connectors to Docker registries. I do'nt know how well it will work here.

Thanks,
Alana

Hi @vdubrovskyi_1854 ,

Unfortunately this is just how composer works; it never requests the metapackage from the server (i.e. ProGet) nor does it upload the composer.lock file to ProGet.

There is obviously no way for ProGet to "guess" what metapackages you may want. Obviously, ProGet does not automatically download/install every metapackage from the upstream repository. That's obviously not behavior anyone would want, and we will not add it to ProGet.

You have two options:

1. Modify the behavior of composer to request these packages from ProGet,
2. Writing a script to parse your composer.lock and then download and/or promote those files within ProGet

Hope that helps,

Alana

Hi @vdubrovskyi_1854 ,

I'm not an expert on how Composer handles packages, but so far as I can tell the behavior you’re seeing is expected and is how metapackage types are handled.

A metapackage does not contain any files and is not installed into the vendor/ directory. It exists only to define dependencies on other packages. There is no contents in the package and thus, there is nothing for Composer to fetch.

Because of this:

• It will appear in composer.lock as part of dependency resolution
• It will not create a directory under vendor/
• The content itself is not be fetched (downloaded) from Composer
• Only the Composer API is queried

ProGet can only cache a package when a download/fetch occurs. Since metapackages are not fetched, there is nothing to cache.

When you downloaded manually, you are deviating from Composer’s normal install behavior for metapackages -- so that's why it appears.

In summary, this behavior is expected and not an error in ProGet. Unfortunately there's no way for ProGet to cache these packages, since Composer never downloads them.

Hope that helps,

Alana