We have the full gamut of environments. Those with unfettered access to the unwashed internet, proxied environments, a single machine with access we can tunnel through, to, yes, SCIF-levels of lockdown. In all of those scenarios, we offer an offline prep script that bundles everything needed for the installation into a zip file, which you can then sneaker-net into the environment and continue the installation. I think we can make the offline installation work based on what I'm seeing in the documentation. I just wanted to make sure it was a "supported" mechanism of installation.

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: Modify the behavior of composer to request these packages from ProGet, Writing a script to parse your composer.lock and then download and/or promote those files within ProGet Hope that helps, Alana

Ok @atripp, thanks for getting back to me. I'll see if I can include the deployment ID and return code as key-value pairs in the build instead. Have a nice day, Anthony.

Hi @sigurd-hansen_7559, This is a known issue, PG-3246, and will be fixed on Friday in ProGet 2025.25. Thanks, Rich

Thanks for the heads up @felfert ! Looks like we're back now, looks like there was some issue reporting the outage on our end :) Alana

Hi @atripp, @gdivis, we have checked this issue today and all seems to work like a charm. Big thanks for quick and really good work :) Best regards

Hi @_moep_ , So there are quite a few "moving pieces" here. Vulnerability -> Assessment -> Compliance -> Build Issue Vulnerabilities & Assessments First and foremost, when you navigate to qs@0.6.6 in the ProGet UI, you should see several vulnerabilities listed, such PGV-2287703. So, the "identification" is there as a result of the offline version of that database being included with ProGet. But, ProGet is all about reducing noise while helping elevate real risks - and most vulnerabilities are theoretical, have no real-world exploits, would require a dedicated attacker, and would result tin no real damage. A "Denial of Service from Prototype Pollution" is great example of such a vulnerability. The risks and problems introduced by reactively upgrading every dependency far exceed any benefits -- moreover, it "de-sensitizes" everyone to real security risks. The idea of "when everything is severe nothing is" is the same as "when everything is a priority, nothing is". That's where Assessment comes in. In ProGet 2025 and earlier, a vulnerability is generally as "assessed" Ignored, Warn, or Blocked. PGV-2287703 will be assessed as Warn by default. **NOTE this will be changing in ProGet 2025. ** Policies & Compliance Next, there's the question of Compliance; the vulnerability assessment (among other things, like license, deprecation status, etc) will determines whether or not a package is Compliant, Noncompliant, or Warn. Compliance rules are configured in policies. In ProGet 2025, by default, the "Warn" Assessment will not make a package Noncompliant. Just Warn. Builds & Issues A Build is considered Noncompliant if any of the packages are Noncompliant. A Noncomplaint build should be blocked from deploying to production. This is where Issues come in: an issue may be created when a build is analyzed (try it out by clicking [analyze] in the UI) for a Noncompliant package. The purpose of these Issues are to effectively "override" the compliance status on a single package. They are not informational; if you want a list of packages, vulnerabilities, licenses, just use pgutil builds audit to get that listing. Long story short, I'd decide on a process you'd want to use before even considering web hooks for all this. Also note that this mostly requires a paid license, so you may not even be getting functionality if you're on a free version hope that helps, Alana

SQL Server is super fun! So the account you initially installed ProGet with in Inedo Hub will have permissions in SSMS to modify permissions for the SQL instance. This is because Proget installs SQL for you if you don't already have it installed. If you have the credentials the Proget service used to use, log in to SSMS with those credentials, then create the SQL Server login for the NetworkService account following @atripp's guidance above. Then, when you start the ProGet service, it should "see" the database.

Got this on a NPM feed, which has a connector to *npm-registry.npmjs.org. Recently upgraded to 25.23.11 An error occurred processing a POST request to http://packagemanager.REDACTED/npm/NPM-Source/-/npm/v1/security/advisories/bulk: '0x00' is an invalid start of a property name. Expected a '"'. LineNumber: 0 | BytePositionInLine: 1. System.Text.Json.JsonReaderException: '0x00' is an invalid start of a property name. Expected a '"'. LineNumber: 0 | BytePositionInLine: 1. at System.Text.Json.ThrowHelper.ThrowJsonReaderException(Utf8JsonReader& json, ExceptionResource resource, Byte nextByte, ReadOnlySpan`1 bytes) at System.Text.Json.Utf8JsonReader.ReadSingleSegment() at System.Text.Json.JsonDocument.Parse(ReadOnlySpan`1 utf8JsonSpan, JsonReaderOptions readerOptions, MetadataDb& database, StackRowStack& stack) at System.Text.Json.JsonDocument.Parse(ReadOnlyMemory`1 utf8Json, JsonReaderOptions readerOptions, Byte[] extraRentedArrayPoolBytes, PooledByteBufferWriter extraPooledByteBufferWriter) at System.Text.Json.JsonDocument.Parse(Stream utf8Json, JsonDocumentOptions options) at Inedo.ProGet.WebApplication.FeedEndpoints.Npm.NpmAuditHandler.HandleBulkAdvisory(AhHttpContext context, NpmFeed feed) at Inedo.ProGet.WebApplication.FeedEndpoints.Npm.NpmAuditHandler.TryProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, NpmFeed feed, String relativeUrl) at Inedo.ProGet.WebApplication.FeedEndpoints.Npm.NpmHandler.ProcessRequestAsync(AhHttpContext context, WebApiContext apiContext, NpmFeed feed, String relativeUrl) at Inedo.ProGet.WebApplication.FeedEndpoints.FeedEndpointHandler.FeedRequestHandler.ProcessRequestAsync(AhHttpContext context) ::Web Error on 19.03.2026 19:52:44::

Hi @gbeckett, Glad to hear it is working for you! Please let us know if you run into any other issues. Thanks, Rich

Hi @stevedennis , hi @geraldizo_0690 , sorry for the late reply, it was indeed a timesync issue. Thanks, Matthias

@rhessinger Thank you Rich - will install it once released and confirm it is fixed.

To follow up, we ended up being able to get everything working using userPrincipalName for user identity by switching to the OpenLDAP/GenericLDAP connector. The remaining issue I was seeing - unexpected failed group lookup in the "Test User Directories/Load user by user name" test - appears to have been caused by a quirk in the connector. In this particular test for this particular connector, group names are case sensitive. In the other tests for this connector, and in all the tests in the AD connector, group name case is ignored. This does not seem to have any repercussions in actual use, but it led us a merry dance for a while.

Hi @certificatemanager_4002 , From the cybersecurity perspective, it's fine to leave it as root since the core process is run by the non-root user postgres inside of the container. You're never exposing a network service while the containerized process has root privileges. Here is more information on this if you're curious: https://stackoverflow.com/questions/73672857/how-to-run-postgres-in-docker-as-non-root-user As you can see in that link, it's technically possible to configure as non-root, but it requires more effort and doesn't really get you any benefit. As for load-testing and restarting, it really depends on the hardware and similar factors. Keep in mind that InedoDB is simply the postgresql container image with some minor configuration tweaks/changes. So any question you ask about InedoDB you can really ask about postgresql as well. As for using an external PostgreSQL server, the only information we have at this time is in the link I sent you before. You really need to be an expert on PostgreSQL if you wish to run your own server. Thanks, Alana

It looks like someone (at IP 10.2.12.133) has configured the wrong URL in Visual Studio or something. They are trying to access the NuGet API via the wrong URL (note the /feeds vs /nuget at the base url). Cheers, Alana

As I understand it, having a user with dbo-role is not sufficient(according to stackexchange). Since our user is role dbo, but not set as owner on the database, it does not work. Anyway, this is not a problem for us since we do run this manually :)

Ay thank you so much. Yes. It's an air-gapped network. I found the files and have made a docker volume back to the machine.

Ah, fantastic - thank you. I'll keep an eye out for it!

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