Hi there!

We run Proget as an Azure Container Web App atm with great success. To this we have an Azure SQL DB and we have mounted an Azure storage account file share at /var/proget to get all the files stored in Azure and backed up there. Everything deployed with Bicep, which is awsome

There are some cool features for Azure Web Apps though that I would like to utilize to maximize the robustness and up time of our Proget instance for our developers.

One such feature is the "scale out" together with "Health check". This (if I understand correctly) would allow me to run multiple instances of the Proget container and Azure will ping them to see if they are healthy. If one is deemed unhealthy it will be brought down and replaced.

I however have some concerns about what happens if I scale out the web app to multiple instances but they all have the same SQL database and file share? The file share shouldn't be an issue, but what about the database? Can it handle writing and reading from multiple instances of an Azure Container Web App? Do you have any experience or best practices regarding this? I'm not very experienced with DB:s, and my biggest concern is that there will be any deadlock, corrupt data and overall breakage of the data in the DB, but maybe that is not a concern.

Also when on the topic, do you have any recommended path to probe/ping for checking health of both the Proget instance and the SQL DB connection?

I guess some endpoint which tries to read something from the DB and returns a non 200-299 code if the read fails would be good. It should be something "static" and not a path to a package which could be removed any time in the future.

(If there are concerns with the DB I guess a single instance with "auto replace" by the health check is good enough, but this would cause a one hour downtime which would be nice to not have )

It should be noted that we do not have any kind of load on Proget since we are pretty few devs, I would only like to use these features to increase the uptime and robustness of the app since people will come and complain at me if Proget is down

Cheers
Carl

And just as an FYI (not a complaint at all), for that specific post... we'd really only need the stack trace. The technical details.... they were.... well, as you said, you used AI

Haha @stevedennis I understand, no offence taken

Thanks for the configuration as code post there seems to be some workarounds to actually being able to configure some things through code though I think apxltd has litte bit too pessimistic take on configuration as code It sounds like he has had to taste only the bad side of it. If properly set up with working processes I only think its good. The most important thing being review and versioning of the deployment of the infrastructure with Proget setup included imo

But we can continue the discussion in the configuration as code thread instead

Hi @stevedennis, I understand your point but I don't think it would hurt anyone in providing more through the API, both when it comes to logs and control/settings.

One of the areas in which I think Proget is lacking compared to other similar solutions is precisely the control and information/log readout from the application itself in programmatic ways using for example the API. Having to fetch logs and do settings only in the GUI through point and click makes it hard to do versioning and reviews of settings as code.

As an example of AI usefulness, this post I did last week, which resulted in a real bug, PG-3399 was all work of my Opus 5.5 agent. I did not even write the forum post, it was all AI and it resulted in finding a real problem.

https://forums.inedo.com/topic/5850/pypi-connector-to-azure-artifacts-returns-401-same-url-and-pat-work-with-curl?_=1792409820070

I understand your fear of customers doing weird stuff due to incorrect feedback from AI.

But then let me rephrase the question without AI in the picture, I would like more control of the application through API, both settings and diagnostics readout :) it would not hurt, it would only make Proget the stronger choice on the market :) I think the uprising of API first applications talks for itself.

Hi there!

I've had to work with the Diagnostic Center lately and it's been a hassle to copy paste messages from the GUI to my AI agent.

I've tried to find ways for my agent to get access directly to all logs and error messages but it does not seem to be natively in the API?

Do you have any workaround or would it be possible to add this to the API? :) I think a lot of information is missed when I manually have to give it to my agent when fault tracing.

Cheers
Carl

@rhessinger It's ok, we can wait a couple of days :) have not rolled out the switch over from ADO to Proget fully yet. Thanks anyway! :)

Thanks @rhessinger for the quick response and quick fix! One of the many reasons we choose Proget

Thanks @rhessinger

We've imported the packages in the meantime, so we're not blocked.

For reference, the Azure side answers our requests fine, including with Accept: application/vnd.pypi.simple.v1+json, where the JSON contains the files list with url and hashes.sha256 for every file.

Cheers
Carl

Hi there! I have some problems hooking up our Azure Artifacts pypi feed to Proget for a smooth transition from Azure Artifacts to Proget, wonder if you have some input :)

ProGet 2026.11 (Build 19), Basic Edition. PyPI feed with a connector to an Azure Artifacts PyPI feed:

• Connector URL: https://pkgs.dev.azure.com/<org>/_packaging/<feed>/pypi (simple path left at the default simple/)
• Authentication: Basic, user name azure, password = Azure DevOps PAT with Packaging (Read)

Requesting a package through the ProGet feed returns "Package not found", and the Diagnostic Center logs:

Connector error: The remote server returned an error: (401) Unauthorized.
System.Net.WebException ... at Inedo.ProGet.Feeds.Pypi.PypiConnector.GetSimpleProjectDetailAsync(String projectName, ...) PypiConnector.cs:line 102

The same request from the ProGet host's network with curl succeeds: curl -u azure:<PAT> https://pkgs.dev.azure.com/<org>/_packaging/<feed>/pypi/simple/<package>/ returns 200, for both the HTML and the application/vnd.pypi.simple.v1+json Accept header. With a valid PAT Azure returns 404 for wrong paths, so the 401 means the connector's credentials are not accepted. Re-entering the password in the UI and via the management API makes no difference. Azure's 401 challenge lists three schemes in this order: WWW-Authenticate: Bearer authorization_uri=..., Basic realm="...", TFS-Federated. Is it possible the Basic credentials are only sent after a challenge and the Bearer entry is picked instead? Is there a way to make the PyPI connector send Basic credentials preemptively?

Cheers
Carl

@atripp award for fastest forum response goes to you yep that seems to have solved it :) simple enough ;) Thanks!

Maybe it would be an idea to highlight or add a little orange "stalled" badge on the ones in the list that causes the warning? Just a nice to have.

Cheers
Carl

This message popped up today, clicking it takes me to the Service Status page, which gives me nothing :p do you have any idea how to proceed and find the culprit? :)

@stevedennis sounds perfect, thanks Steve! :)