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

Reverting to 25.0.9 did actually work in our case So there seems to be some issue with 25.0.10

I also got an error like this

Unhandled exception: Could not find stored procedure 'Executions_FailRunningExecutions'.

@viceice does your /health also show "no problems"?

Having some wierd behaviours with Proget after updating to 25.0.10 my /health responds 200 and shows that there are no issues, so no alerts are firing

{
"applicationName": "ProGet",
"databaseStatus": "OK",
"databaseStatusDetails": null,
"extensionsInstalled": {
"ProGet": "25.0.10",
"Inedo.SDK": "3.1.0",
"Amazon AWS": "3.1.3",
"InedoCore": "3.0.5",
"Azure": "3.1.2"
},
"licenseStatus": "OK",
"licenseStatusDetail": null,
"versionNumber": "2025.10 (Build 11)",
"releaseNumber": "25.0.10",
"startTime": 1758271289653,
"serviceStatus": "OK",
"serviceStatusDetail": null,
"replicationStatus": {
"serverStatus": null,
"serverError": null,
"clientStatus": null,
"clienterror": null,
"incoming": [],
"outgoing": []
}
}

But trying to go to the website I only get http error 500

The logs show an error "Could not find stored procedure 'Security_GetRoles'

2025-09-19T09:04:08.8094686Z info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
2025-09-19T09:04:08.8095216Z       Request starting HTTP/1.1 GET http://proget.dev.companyname.com/health - - -
2025-09-19T09:04:08.8097717Z info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
2025-09-19T09:04:08.8099365Z       Request finished HTTP/1.1 GET http://proget.dev.companyname.com/health - 200 619 application/json 0.3870ms
2025-09-19T09:04:10.6672063Z info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
2025-09-19T09:04:10.6672953Z       Request starting HTTP/1.1 GET http://proget.dev.companyname.com/ - - -
2025-09-19T09:04:10.6687087Z An error occurred in the web application: Could not find stored procedure 'Security_GetRoles'.
2025-09-19T09:04:10.6778579Z info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
2025-09-19T09:04:10.6779411Z       Request finished HTTP/1.1 GET http://proget.dev.companyname.com/ - 500 0 - 10.6553ms
2025-09-19T09:04:13.8057598Z info: Microsoft.AspNetCore.Hosting.Diagnostics[1]
2025-09-19T09:04:13.8058173Z       Request starting HTTP/1.1 GET http://proget.dev.companyname.com/health - - -
2025-09-19T09:04:13.8064277Z info: Microsoft.AspNetCore.Hosting.Diagnostics[2]
2025-09-19T09:04:13.8064479Z       Request finished HTTP/1.1 GET http://proget.dev.companyname.com/health - 200 619 application/json 0.4290ms
2025-09-19T09:04:13.9852857Z info: Microsoft.AspNetCore.Hosting.Diagnostics[1]

Anyone stumbled upon something similar and have any ideas on how to fix this?

Cheers
Carl

@apxltd I understand what you mean

When I have your attention I would like to just tell you that you have done an amazing work on ProGet as a product. It has everything we need while not being overcomplicated or overpriced. It really is a great product.

And the support through this forum is also always superb, fast and accurate.

Great work!

@apxltd I see, thanks for the info!

The use cases seems legit I think, like bundling multiple packages. Why would you like to have it undone?

I stumbled upon this V symbol when scrolling through Inedos open feeds. What does it mean and how does one add it? :)

@dean-houston

Ahh, thanks for pointing that out :)

As an answer to my question about health (and for anyone coming here in the future), I should've just read the docs properly, it was very clear what to check I love Proget! These things just exists and are well documented 🥰

https://docs.inedo.com/docs/proget-reference-api-health

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