I have tried using Arch on a (personal) server and while it certainly works, I would not recommend for production. There are just too many moving parts there and while breakage is extremely rare (especially when carefuly reading the news), it still happens and most companies or organisations prefer a cumbersome, planned upgrade to the next version over many very small possibilities for a catastrophe.

The ease of building packages is indeed one of Arch’s strengths, it enables the AUR and therefore Arch has one of the easiestto use and largest repos out, but again, for production, you should go with containerisation IMO. Docker images are easy to build as well, OS independant and, most importantly independet from system libraries.

Imagine following scenario: You’re running a SaaS based on some python framework. Option 1, you’re running it as a pacman package. If have to use a library that isn’t in the official repos, then you’re fucked when a Python update comes that requires update libraries, you have to update your own app AND the library yourself or do some nasty downgrading, lots of manual intervention required. Or a library you used updates and changes its functionality so that you have to adjust your app. Option 2, you trash the easy to build system packages and go for a virtual enviroment. Now you’re at least protected from the library problems, everythings stale unless you update within with pip, but you lost the easy packaging aspect. But breakage isn’t 100% ruled out, even with the venv you can still encounter problems with updates of stuff that is between your App and the web. All the system stuff could be subject to change in any Syu. And venv is a python only solution, so everything that has other parts is no option. So Option 3, build containers, connect them, deploy them, run them on systems with very little changes in system applications.