Hi @tyan-yin_2201,

It looks like it's only supported on FeedCommand -- I'm not entirely sure why. It appears to be settable when calling the HTTP API however.

We ought to be able to add it relatively easy, but can you share the use case? It's also good to know why someone would want to explicitly set an api key from command line (most tools don't seem to support this).

-- Dean

Hi @udi-moshe_0021 ,

It looks like there's something wrong with your configuration file:
https://docs.inedo.com/docs/installation/configuration-files

It looks like there's a bad/missing PostgreSQL string in there. I don't know how that happened.

-- Dean

Hi @udi-moshe_0021 ,

If you can try it now, the installer should be published.

-- Dean

Hi @udi-moshe_0021 ,

I'm sorry I'm not really able to understand what the specific issue is based on your response. If you can share specific error messages or specific things you're seeing, we might be able to help.

Otherwise there are no known issues installing ProGet on Windows, and if you're having an issue it's almost always a security/antivirus tool that's interfering with modifying system configuration.

-- Dean

Hi @udi-moshe_0021,

If there was no error during installation, it's hard to say; perhaps something is going on with the Windows Service registry, or you need to refresh, or who knows.

I would try rebooting and then installing again.

There is no service for Postgres, just INEDOPROGETSVC

-- Dean

Hi @mayorovp_3701,

This is a bug you should definitely report to GitLab -- it's clearly required by the API and all other registries support it. Without that API defined, we have to "make guesses" based on undocumented conventions (i.e. /v3-flatcontainer/{id}), which causes headaches down the line. That's why there's an API contract :)

I don't know how/why it works with dotnet sdk -- perhaps it's using a different endpoint, or maybe it's not actually working and just going to NuGet.org. Whatever the case, it doesn't make sense for us to build workarounds for easily-fixable bugs on GitLab when other vendors seem to follow the API contract.

-- Dean

Hi @jw ,

Nice catch, we'll add pgutil builds delete and pgutil builds projects delete via PG-3189

You may be able to use pgutil builds create to archive a build (`--inactive), but I'm not sure. Either way, there's no way to flip it back, so we will update it.

The create command can also update, but it's not clear, so we will edit the help text to clarify.

-- Dean

Hi @m-lee_3921,

When specifying a package source, the package must be in the same feed; you could specify it using a URL however.

   {
    "virtualPath": "common/logo/logo.png",
    "source": { 
       "url": "http://proget/endpoints/customer-assets/content/ast-logo.png"
    }

Good point on the documentation; download-vpack is for the .vpack file only (i.e. manifest). I'll update it

-- Dean

@uel_2013 (I deleted my previous reply since I learned a few more details from a team member who talked with you already)

Given your team size, you'd definitely be better off upgrading (rethinking) your CI/CD processes when switching over to BuildMaster. As some users have told us, the Octopus Deploy way is like "trying to apply the SVN mindset in a Git world".

The main benefit to a small team is that it's a simplification/consolidation of build- and deployment tools, while also giving you a powerful platform and process. We're working on "codifying" this in an upcoming guide called Lean Platforms: Engineering & Orchestration.

You could likely get BuildMaster to work in a similar way (i.e. a "deployment script runner"), but you'll be "fighting against the current" and you would be missing out nearly all of the benefits. For example, we have different ways of handling multi-tenancy (e.g. depending on if you do quasi-custom software) and the Git and Issue-tracking integration will make a huge difference in your internal processes.

I'd suggest taking a quick tutorial of the software (you can freely download it), and see how far you can get with setting a basic application from scratch. That should help you see the differences and how the concepts maps. There are a lot of similar ideas, but like Git and SVN, there are differences that don't translate very well.

-- Dean

Hi @thomas_3037 and @felfert ,

We heard from another users that creating a new signing key in the feed worked, so please try that.

We didn't experience that in our testing, but I suppose it's not all that unexpected given the scope of the changes. We will update the documentation / blog post and also try to put some guidance in the software via PG-3157 to help other users who encounter an error like this.

-- Dean

Hi @rick-kramer_9238 ,

It looks like you're using ProGet 2023? That functionality was relatively new in that version and there is very possibly some kind of bug linking the two together.

We've since made some big improvements to SCA/compliance, so I would recommend upgrading. Many of the changes were in ProGet 2024:
https://docs.inedo.com/docs/proget-upgrade-2024#new-features-in-proget-2024

-- Dean

Hi @felfert ,

There were major changes to Debian feeds in ProGet 2025.14:
https://blog.inedo.com/inedo/proget-2025-14-major-updates-to-debian-feeds

They were thoroughly tested and we did not encounter issues when upgrading and switching back/forth between versions. As you might imagine, we don't have enough information to help you troubleshoot this - so we'd appreciate if you could investigate further.

It is most certainly a client-related configuration issue and you may need to reconfigure the keys, clear a cache, or something to that effect. Signing keys are typically not changed for already-configured repositories, so this isn't common client behavior.

Please let us know what you find, so we can document appropriately.

-- Dean

Hi @d-kimmich_0782 ,

This behavior is by design; the "publish date" in ProGet 2025 and earlier is whenever a package is added to a feed. This means that, even if a package was published to NuGet.org 3 years ago, the "publish date" will be whenever it was first cached.

However, in ProGet 2025.14 and later, you can change this behavior under "Admin > Advanced Settings > Use Connector Publish Date". This will be the default behavior in ProGet 2026.

This is being done for a similar set of rules you should investigate, which we call Recently Published & Aged Rules :
https://docs.inedo.com/docs/proget/sca/policies#recently-published-aged-rules-proget-2026-preview

-- Dean

Hi @gisleso,

But I'm starting this topic to ask if its expected behavior that formatting of uncached remote packages is a litte off? See screenshots.

Good catch. In this case, the ProGet implementation of the warehouse API (which connectors use) was using the "description" field instead of the "summary" field. Easy fix, it'll be handled via PG-3151 in the next maintenance release

And if anyone have experience with promoting packages including their dependencies I am open to suggestions. (Right now I'm thinking a script that first pull the packages, and the loop to pull/promote the depedencies)

This is frequently requested, but it's simply impossible to do. The only way to solve this is to restore from your unapproved feed, then promote the dependencies into your approved feed.

The reason is that this would require ProGet (or your script) to perform a "dependency resolution" which is impossible to do without environmental context (i.e. other packages installed, operating system, and client configuration).

This is because dependencies are not only specified as ranges (e.g. hypothesis requires sortedcontainers<3.0.0,>=2.1.0) but they often include usage constraints (e.g. hypothesis specifies redis>=3.0.0; when extra=="redis" is specified) and environmental constraints (e.g. hypothesis specifies tzdata>=2025.2 but only when (sys_platform == "win32" or sys_platform == "emscripten") and extra == "zoneinfo").

Only a package manager tool (e.g. pip) can perform dependency resolution, and even then it's not deterministic. This is why lock files are so important too.

-- Dean

Hi @mayorovp_3701,

Based on the message, it appears to be a bug/problem with the GitLab API. It's indicating that the required PackageBaseAddress endpoint is not present in the service index.

Can you share the "service index" (i.e. the index.json) file? It should be present at the root of the API and look something like this: https://api.nuget.org/v3/index.json

-- Dean

Hi @koksime-yap_5909 ,

Data deduplication is an operating-level system function. On Windows, there's the Data Deduplication Feature. There are more options for Linux, but ZFS Deduplication is pretty popular.

-- Dean

Hi @davi-morris_9177 ,

For multi-file packages like PyPI, the entire package (i.e. all the files) is promoted. This is the same in the UI as well.

-- Dean

Hi @Nils-Nilsson,

Thanks for the report; this was a trivial fix and I just committed the change to PG-3138 , which will be in the next maintenance release (Oct 24).

As an FYI, if you uncheck "Restrict viewing download statistics to Feed Administrators" on the Feed Permissions page, then error shouldn't occur.

-- Dean

Hi @koksime-yap_5909 ,

Docker registry import from Sona, JFrog, and other ProGEt instances is coming soon via PG-3128 - we anticipate that in the next maintenance release.

As for Assets, I'm afraid we don't have any support for that planned in the near future - it's relatively easy to write a script that "extracts" them - if you could extract it to a ProGet drop path, then they'll be imported that way.

https://docs.inedo.com/docs/proget/feeds/feed-overview/proget-bulk-import-with-droppath

-- Dean