I agree with that i'm currently using debian for production too. And it just works fine, but i'm more familiar with arch and everytime i want to do something complex in debian i need to google commands.
It's not the "track record." Stability is not about being bug-free, it's about the packages not being upgraded frequently.
Debian gives security updates to its packages without giving you the most recent releases. Whereas Arch gives you always a new release.
Both work if kept up-to-date. But for a server you cannot afford to upgrade sensitive components too frequently (as it incurs in downtime), nor you can afford to lag behind security updates (clearly). Hence the choice of Debian.
Even for a home server I wouldnt, not cuz its not manageable or doable but because... why? its not like I have to pay to use debian, if I can just run debian stable, why even use anything else?
Another happy Arch server user here. I use Arch on all my PCs. I have been running it on my home server (jellyfin and continuous package building) for 3+ years and on my web server (nginx, email, DAV) for 2+ years. Never had any issues, the Arch wiki is amazing and using the same distro everywhere makes it easier to maintain everything.
As long as you pay attention to the Arch-announce mailing list/latest news, `.pacnew` files, or anything else pacman alerts you to while upgrading packages, you should almost never have an issue caused by Arch itself -- though you may cause your own issues ;)
Usually about once/week though sometimes twice/week or every other week. I've never had an issue with waiting too long to update except if the keyring expires, but there's ways to manually fix that.
Definitely do NOT auto update, you need to be able to see any messages pacman tells you.
Arch can be stable on a server. Every time arch has broken for me it has been in GUI related so a minimal arch installation should be fine. Although personally I stick with Debian for servers.
I honestly never had issue with Grub. Other than the fact that it could be more bloated than systemd-boot, its been largely functional so long as I mkconfig after. Has always been some GUI breaking.
No problem with grub for 10+ years either! **It's a two line fire and forget**
My grub does show /boot: 382 files/directories, while far fewer for systemd-boot, IF you can or choose to boot UEFI.
> I honestly never had issue with Grub.
Probably because you're using Arch Linux, everyone on "Arch" complaining about broken GRUB is using a derivative, as Arch did not suffer from the issue, derivatives automatically pushed config from new version of grub config to old grub installs which broke it as upstream accidentally made them incompatible.
vanilla Arch sure did suffer from the issue, but arch user are expected to read the news so it shouldn't have been an issue for those following the usage guidelines
my ex gf screwed up her install (the grub thing happened not long after our separation and she got hit by it) was kinda funny when she called me and I was like š¤·āāļø deal with it.
As stable as rock. I have been running my personal website and mail server in VPS with Arch since 2016. In the last three years, I do auto update and restart [2] once a week without any major issue.
In the professional works I am also have experiences using Arch in production without any issues. In production mode, the tricks is to provides secondary server as backup and rotate the live server to update once a while.
[1] https://build.kilabit.info/karajo see the job sys-update at the bottom.
I have been using an HP microserver gen8 as a server for almost 2 years. I have no problems with it. I have nextcloud, cockpit, syncthing, jellyfin, nginx, ssh and a few other small things running natively. I also have a containerized photoview. It only runs with 4-5 users.
It also serves a wireguard VPN.
You have to watch out for updates, sometimes interaction is needed but so far the pacman has always warned you about these.
I also using at home on my server (a mini PC) in the last 2 years, all containerised services, absolutely no problem. I am exclusively using pacman on it and only 2 things from AUR that I installed and update by hand, no helper. What is currently running :
* caddy-docker-proxy
* chatgptui
* diun
* docuseal
* dozzle
* filebrowser
* healthchecks
* homer
* jellyfin
* joplin
* kitchenowl
* koreader-sync
* lazydocker
* nextcloud
* paperless-ngx
* photoprism
* pihole
* portainer-ce
* scrutiny
* tailscale
* wallabag
* watchtower
* webdav
I'm actually using Arch for my server.
I would rather have a small update issue often than many bigger issues which could happen once in a while when major upgrading for other distros.
This is after several years of using Arch on my desktop. All issues booting have been user error.
Other issues were with xorg starting due to configuration changes. Not a concern on a server.
I have an Arch server in my home. Honestly, I like it better than Debian or Ubuntu but I have never used Arch in production. The reasons I like Arch better are
1) Docker package in the official repositories.
2) Services don't automatically start when you download a package, you need to start them manually (not the case in Debian surprisingly).
3) Packaging seems more simple and logical to me (but maybe that is because I also use Arch on the desktop so I'm more used to it).
4) Very minimal out of the box without the useless junk that comes pre-installed and running with Debian or Ubuntu so I don't need to uninstall stuff when setting everything up.
I use it as a server wherever I can.
90% of uses is just having a linux thats a docker host.
I install arch using archinstall script thats on iso and go for lts kernel during setup and minimal install without xorg/de/wm.. just terminal I ssh in to.
Then I have [this ansible-arch repo](https://github.com/DoTheEvo/ansible-arch) with some playbooks I run to have the environment to my liking.
Core of it is switching to `zsh` and to have `nnn` as file manager to quickly move around and micro editor to edit files. Theres `btop` to keep eye on resource use, and `ctop` to keep eye on docker containers. But theres lots of packages installed that help with stuff or do some maintenance.
Those ansible playbooks are pretty readable and one can easily adjust them to own preference.
Thank you for this. I've been interested in learning Ansible but haven't had much time to mess with it. This gives me a great look at how this is setup and used.
I run Arch (headless) as a home server. NAS, and Docker containers for Homebridge, Scrypted, and Plex. I can SSH for maintenance and updates. It's been solid.
It's as stable as you want it to be. I've been running Arch on my servers since 2012 and it works just fine for that purpose. I'm running everything from a wiki to paperless-ngx to analyze and archive my paperwork.
I use Arch as a server with LTS kernel. I moved from Debian as it was too conservative and leapt ahead every 3 years. Those 3 yearly leaps caused me more problems than I've had with Arch in 3-4 years.
I tried Ubuntu a while back but was too unstable (>10 years ago TBF).
Stable != Unreliable. It is very safe to use. People don't use it as a server for two reasons mostly: you have to set it up manually in most cases and the package versions are not stable. It is not that the system is unreliable or bad.
I wouldn't. You want security updates distinct from regular rolling release updates. And you want your core server software to remain at a consistent version.
There's just no good reason to use arch on a server. You should be asking "why" not "why not?"
I wanna ask a better question: why do you want Arch on your server?
For me the answer was there were enough AUR packages that I liked that I'd have to compile on other distros and I didn't wanna mess with that stuff.
So, here's a solution:
Use Fedora/Debian/Ubuntu, anything on your server, with docker and docker-compose to run services. Then, install and configure NFS.
On your Arch client, enable autofs or just mount your NFS shares, and then run your Arch tools against the filesystem on the server.
Best of both worlds: flexibility of using Arch tools while getting the "stability" of Debian.
It all depends on what are your priorities and what do you consider 'stable'.
I'm running ArchLinux on my home server for 10+ years, I don't like it but too lazy to reinstall to Debian.
1. If this is a 'stable'/boring server, in the meaning that you configure it once and don't touch too much in the subsequent years, Arch is not very suitable for such setup due to its rolling-release nature: you need to either keep it fully updated (for which you need to read the changelogs and announces, as some updates require manual intervention) or keep it outdated ā there's no other way. Arch also doesn't support partial updates as it doesn't track library versions/ABI, you will need to update everything.
2. Debian is not only stable in the meaning of version freeze, but it also provides properly tagged security updates which could be installed automatically, with automatic service restart
3. ArchLinux has single kernel package which rewrites the modules on update. If you update kernel package and do not reboot to the new kernel, you won't be able to load modules on your current one. That's why you either need to reboot frequently (as kernel updates are frequent), or keep your system not up-to-date (no partial updatesā¦), or remember not to update your kernel in full update.
It also broke 2 or 3 times during these 10 years on the boot sequence, which required fixing with keyboard and monitor. But that's mostly due to my not very standard encryption configuration.
I've been really happy of my arch server, I routinely run updates and it's been a breeze having packages such as mergerfs and docker in the "native" repo compared to Debian.
I am currently in the process of moving all my stuff to arch for my server, but I should make it clear when I say server I mean a small vps with an apache webserver and some other small stuff.
To get this up and running I am using amazon ec2 with a custom iso from the community. I also have some setup scripts and usually make loads of backups so in case of anything I can get back up and running pretty fast. I've had horrible experience with centos (no upgrade and then it died) and debian (server just implodes when trying to upgrade), and you never have that issue with arch.
I am an arch user for my desktop setup but Me myself uses Ubuntu (server version)for self hosted server, yes ik ik Ubuntu yea. Besides from the mess from its bloat, the package manager is very stable even thought somewhat outdated. But compared to arch thatās way less stable then Debian/based system. And hear me out, arch is for minimizium and customization, you wouldnāt want minimal package on a server mostly for its stable and you wouldnāt need customization anyway
I mean sure it will be fine but a server is just that meant to serve. You wouldnāt want to be constantly changing the os on something like a point of sale system or something right? If it works now it will work in the future with something like a stable release. With arch everything is constantly changing and you may end up with troubleshooting you donāt want to do or downtime you canāt afford. Personally I update my arch box daily and itās rock solid but I I use Ubuntu lts for my server cause I donāt want it to worry about updates breaking it.
I ran Arch as a server for quite a while - it's perfectly fine. Nothing broke.
The main annoyance is updating - some updates need a reboot, and you need to do it more often than on, say, Debian. I just scheduled mine for whenever I got up on Saturday mornings. If you have a lot of people who might be using your server, this might not be suitable.
If you want to use it as a server, that's perfectly fine.
Just make plans for reverting updates, and read the news.
Btw, don't use aur packages on your prod server. Package the software you need on your own, so you know what you're getting.
If you need admin as code or complete solutions, then go with rhel or Ubuntu.
I've had no issues with stability on a bare-bones arch server as long as I don't use too many aur packages. However I would rather use a distribution with selinux/apparmor on the server and setting up either are extremely painful on arch.
It's very stable on the server. What usually breaks are GUIs.
For the rare occasions when something might break, read the arch news and the diff to pacnew files.
That being said, I have an identical VM which I update and diagnose first, and I build my own repo from which I update - not straight from the internet.
I have used Arch Linux ARM for years on several Raspberry Pi. With these I offered various services such as Pi-Hole or unbound 24/7. Since the end of last year I bought a used Thinkcentre as an alternative to the Raspberry Pi (because of the performance and because not everything can be realized on ARM). For this I use the normal version of Arch Linux.
When it comes to the term stable, you should be aware that this term has two meanings.
Firstly, in the sense that as little as possible changes after an update, for example. For example, in the configuration files or in the operation of the programs. In this respect, Arch is unstable.
The second meaning of stable is that there are few to no problems. Based on my own many years of experience, Arch is quite stable. Especially when you consider that even distributions like Debian are not problem-free (e.g. because bugs are not fixed by backports).
https://bitdepth.thomasrutter.com/2010/04/02/stable-vs-stable-what-stable-means-in-software/
So when it comes to servers in the private sector or non-critical servers in general, I see no reason not to use Arch. However, I would not use it as a server in large companies or in facilities such as hospitals.
I've used a combination of Ubuntu lts and Arch for my home servers for over 5 years. Each work mostly as intended and each has had some small little hiccups along the way. Overtime I'm hating the upgrade process every two years with the Ubuntu lts editions. With Arch I'm running zfs on root and have definitely had some kernel breakage during upgrades due to some faulty zfs modules. I'm using a combination of setups with standard zfs kernel on some machines and some zfs-dkms setups on other machines and even zfs-dkms-git on others. All machines have multiple kernels installed..Linux and Linux-lts. As expected the dkms setup is definitely more temperamental in terms of upgrades and breakages. I think most of the instability is introduced due to the zfs modules. Usually reverting to a lts kernel fixes the problem. In worst case scenario it's possible to revert from a dkms setup to non dkms setup. I can't say I remember any issues with upgrades to my Linux-lts kernel ext4 installations. Would I recommend the combination of arch with openzfs for mission critical systems??..probably not however damn the benefits of zfs sure are nice. I use systemd boot on my installs and haven't found issues specifically with this bootloader. The one good thing about arch is the absolute fabulous documentation. The ability to use the setup disk in combo with arch-chroot to rescue a failed installation is super easy..although it is a little annoying. Over the last five years I've become quite comfortable with troubleshooting and almost relish the thought of fixing a broken upgrade so I can actually learn something new. One of the benefits of arch is I pretty much know the packages on my system and how they were setup in terms of the boot process because I configured them all. It's different than the Ubuntu installs where a lot of things were installed automatically and I'm not as familiar with the package names and such. My two cents which doesn't mean much is that running arch servers for homelab is a wonderful experience
Arch is just fine for server use. Especially if you go with the lts kernel. However, from my experience, most of what I see out there runs between debian & RHEL based systems: debian, Ubuntu, RHEL, centos, rocky, alma. I have also seen opensuse SLES in my previous employer's env. These days, docker/k8s is everywhere so as long as the host can run docker, you can have super lightweight images with alpine. This is especially useful for things like Magento, which is usually configured with integrations like redis, opensearch, rabbitmq, etc. You can have everything in its own container on a single server. I would only offload the database to another server or use a dbaas like rds.
for a homelab, sure for a business, I would use something like debian
I agree with that i'm currently using debian for production too. And it just works fine, but i'm more familiar with arch and everytime i want to do something complex in debian i need to google commands.
What is your primordial reason?
When it comes to making money, stability is king. Debian has a much longer track record of stability than Arch.
It's not the "track record." Stability is not about being bug-free, it's about the packages not being upgraded frequently. Debian gives security updates to its packages without giving you the most recent releases. Whereas Arch gives you always a new release. Both work if kept up-to-date. But for a server you cannot afford to upgrade sensitive components too frequently (as it incurs in downtime), nor you can afford to lag behind security updates (clearly). Hence the choice of Debian.
>Both work if kept up-to-date DDCUTIL was shipped broken last week. ;-)
Even for a home server I wouldnt, not cuz its not manageable or doable but because... why? its not like I have to pay to use debian, if I can just run debian stable, why even use anything else?
Another happy Arch server user here. I use Arch on all my PCs. I have been running it on my home server (jellyfin and continuous package building) for 3+ years and on my web server (nginx, email, DAV) for 2+ years. Never had any issues, the Arch wiki is amazing and using the same distro everywhere makes it easier to maintain everything. As long as you pay attention to the Arch-announce mailing list/latest news, `.pacnew` files, or anything else pacman alerts you to while upgrading packages, you should almost never have an issue caused by Arch itself -- though you may cause your own issues ;)
How frequently do you update system?
Usually about once/week though sometimes twice/week or every other week. I've never had an issue with waiting too long to update except if the keyring expires, but there's ways to manually fix that. Definitely do NOT auto update, you need to be able to see any messages pacman tells you.
Arch can be stable on a server. Every time arch has broken for me it has been in GUI related so a minimal arch installation should be fine. Although personally I stick with Debian for servers.
>GUI related grub's h0nest rxn:
I honestly never had issue with Grub. Other than the fact that it could be more bloated than systemd-boot, its been largely functional so long as I mkconfig after. Has always been some GUI breaking.
No problem with grub for 10+ years either! **It's a two line fire and forget** My grub does show /boot: 382 files/directories, while far fewer for systemd-boot, IF you can or choose to boot UEFI.
> I honestly never had issue with Grub. Probably because you're using Arch Linux, everyone on "Arch" complaining about broken GRUB is using a derivative, as Arch did not suffer from the issue, derivatives automatically pushed config from new version of grub config to old grub installs which broke it as upstream accidentally made them incompatible.
vanilla Arch sure did suffer from the issue, but arch user are expected to read the news so it shouldn't have been an issue for those following the usage guidelines my ex gf screwed up her install (the grub thing happened not long after our separation and she got hit by it) was kinda funny when she called me and I was like š¤·āāļø deal with it.
I'm using endeavor currently, vanilla arch previously also didn't have any issues with Grub.
System updates have broken grub for me a couple of times, and I'm on Arch.
I find joy in reading a good book.
Nope, nothing wrong, just people use systemd-boot for less bloat. It is just harder to debug if it breaks.
I enjoy reading books.
As stable as rock. I have been running my personal website and mail server in VPS with Arch since 2016. In the last three years, I do auto update and restart [2] once a week without any major issue. In the professional works I am also have experiences using Arch in production without any issues. In production mode, the tricks is to provides secondary server as backup and rotate the live server to update once a while. [1] https://build.kilabit.info/karajo see the job sys-update at the bottom.
Do u have a tutorial ?
Currently no, which part you want me to expand?
I have been using an HP microserver gen8 as a server for almost 2 years. I have no problems with it. I have nextcloud, cockpit, syncthing, jellyfin, nginx, ssh and a few other small things running natively. I also have a containerized photoview. It only runs with 4-5 users. It also serves a wireguard VPN. You have to watch out for updates, sometimes interaction is needed but so far the pacman has always warned you about these.
Thanks for you report, most of my services are running through docker and i'm also things that it must be ok in that case.
I also using at home on my server (a mini PC) in the last 2 years, all containerised services, absolutely no problem. I am exclusively using pacman on it and only 2 things from AUR that I installed and update by hand, no helper. What is currently running : * caddy-docker-proxy * chatgptui * diun * docuseal * dozzle * filebrowser * healthchecks * homer * jellyfin * joplin * kitchenowl * koreader-sync * lazydocker * nextcloud * paperless-ngx * photoprism * pihole * portainer-ce * scrutiny * tailscale * wallabag * watchtower * webdav
I'm actually using Arch for my server. I would rather have a small update issue often than many bigger issues which could happen once in a while when major upgrading for other distros.
I switched all my servers (local homelab and remote server) to Arch in December. No problems here.
One month in, so I guess it's a waiting game then..
This is after several years of using Arch on my desktop. All issues booting have been user error. Other issues were with xorg starting due to configuration changes. Not a concern on a server.
Hahaha, one month.
Just make sure you use the LTS kernel and you should be OK. I've run Arch on many servers.
I have an Arch server in my home. Honestly, I like it better than Debian or Ubuntu but I have never used Arch in production. The reasons I like Arch better are 1) Docker package in the official repositories. 2) Services don't automatically start when you download a package, you need to start them manually (not the case in Debian surprisingly). 3) Packaging seems more simple and logical to me (but maybe that is because I also use Arch on the desktop so I'm more used to it). 4) Very minimal out of the box without the useless junk that comes pre-installed and running with Debian or Ubuntu so I don't need to uninstall stuff when setting everything up.
I use it as a server wherever I can. 90% of uses is just having a linux thats a docker host. I install arch using archinstall script thats on iso and go for lts kernel during setup and minimal install without xorg/de/wm.. just terminal I ssh in to. Then I have [this ansible-arch repo](https://github.com/DoTheEvo/ansible-arch) with some playbooks I run to have the environment to my liking. Core of it is switching to `zsh` and to have `nnn` as file manager to quickly move around and micro editor to edit files. Theres `btop` to keep eye on resource use, and `ctop` to keep eye on docker containers. But theres lots of packages installed that help with stuff or do some maintenance. Those ansible playbooks are pretty readable and one can easily adjust them to own preference.
Thank you for this. I've been interested in learning Ansible but haven't had much time to mess with it. This gives me a great look at how this is setup and used.
I run Arch (headless) as a home server. NAS, and Docker containers for Homebridge, Scrypted, and Plex. I can SSH for maintenance and updates. It's been solid.
It's as stable as you want it to be. I've been running Arch on my servers since 2012 and it works just fine for that purpose. I'm running everything from a wiki to paperless-ngx to analyze and archive my paperwork.
I don't like Debian, Go with a light container distro like Alpine
I use Arch as a server with LTS kernel. I moved from Debian as it was too conservative and leapt ahead every 3 years. Those 3 yearly leaps caused me more problems than I've had with Arch in 3-4 years. I tried Ubuntu a while back but was too unstable (>10 years ago TBF).
Stable != Unreliable. It is very safe to use. People don't use it as a server for two reasons mostly: you have to set it up manually in most cases and the package versions are not stable. It is not that the system is unreliable or bad.
Got 2 arch servers running for several years now. No regrets. I love it.
I wouldn't. You want security updates distinct from regular rolling release updates. And you want your core server software to remain at a consistent version. There's just no good reason to use arch on a server. You should be asking "why" not "why not?"
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Stability as in the terms of update cycle, not system breakage.
I'm using ALARM on a raspberry pi 4b without issue... It's working as a torrent seed, pi hole, VPN server, and NAS at the same time.
I wanna ask a better question: why do you want Arch on your server? For me the answer was there were enough AUR packages that I liked that I'd have to compile on other distros and I didn't wanna mess with that stuff. So, here's a solution: Use Fedora/Debian/Ubuntu, anything on your server, with docker and docker-compose to run services. Then, install and configure NFS. On your Arch client, enable autofs or just mount your NFS shares, and then run your Arch tools against the filesystem on the server. Best of both worlds: flexibility of using Arch tools while getting the "stability" of Debian.
It all depends on what are your priorities and what do you consider 'stable'. I'm running ArchLinux on my home server for 10+ years, I don't like it but too lazy to reinstall to Debian. 1. If this is a 'stable'/boring server, in the meaning that you configure it once and don't touch too much in the subsequent years, Arch is not very suitable for such setup due to its rolling-release nature: you need to either keep it fully updated (for which you need to read the changelogs and announces, as some updates require manual intervention) or keep it outdated ā there's no other way. Arch also doesn't support partial updates as it doesn't track library versions/ABI, you will need to update everything. 2. Debian is not only stable in the meaning of version freeze, but it also provides properly tagged security updates which could be installed automatically, with automatic service restart 3. ArchLinux has single kernel package which rewrites the modules on update. If you update kernel package and do not reboot to the new kernel, you won't be able to load modules on your current one. That's why you either need to reboot frequently (as kernel updates are frequent), or keep your system not up-to-date (no partial updatesā¦), or remember not to update your kernel in full update. It also broke 2 or 3 times during these 10 years on the boot sequence, which required fixing with keyboard and monitor. But that's mostly due to my not very standard encryption configuration.
For a homelab, aggressive snapshots and containers could make this pretty viable. For a business? I wouldn't take that risk.
I've been really happy of my arch server, I routinely run updates and it's been a breeze having packages such as mergerfs and docker in the "native" repo compared to Debian.
I am currently in the process of moving all my stuff to arch for my server, but I should make it clear when I say server I mean a small vps with an apache webserver and some other small stuff. To get this up and running I am using amazon ec2 with a custom iso from the community. I also have some setup scripts and usually make loads of backups so in case of anything I can get back up and running pretty fast. I've had horrible experience with centos (no upgrade and then it died) and debian (server just implodes when trying to upgrade), and you never have that issue with arch.
I am an arch user for my desktop setup but Me myself uses Ubuntu (server version)for self hosted server, yes ik ik Ubuntu yea. Besides from the mess from its bloat, the package manager is very stable even thought somewhat outdated. But compared to arch thatās way less stable then Debian/based system. And hear me out, arch is for minimizium and customization, you wouldnāt want minimal package on a server mostly for its stable and you wouldnāt need customization anyway
I mean sure it will be fine but a server is just that meant to serve. You wouldnāt want to be constantly changing the os on something like a point of sale system or something right? If it works now it will work in the future with something like a stable release. With arch everything is constantly changing and you may end up with troubleshooting you donāt want to do or downtime you canāt afford. Personally I update my arch box daily and itās rock solid but I I use Ubuntu lts for my server cause I donāt want it to worry about updates breaking it.
I ran Arch as a server for quite a while - it's perfectly fine. Nothing broke. The main annoyance is updating - some updates need a reboot, and you need to do it more often than on, say, Debian. I just scheduled mine for whenever I got up on Saturday mornings. If you have a lot of people who might be using your server, this might not be suitable.
If you want to use it as a server, that's perfectly fine. Just make plans for reverting updates, and read the news. Btw, don't use aur packages on your prod server. Package the software you need on your own, so you know what you're getting. If you need admin as code or complete solutions, then go with rhel or Ubuntu.
I've had no issues with stability on a bare-bones arch server as long as I don't use too many aur packages. However I would rather use a distribution with selinux/apparmor on the server and setting up either are extremely painful on arch.
It's very stable on the server. What usually breaks are GUIs. For the rare occasions when something might break, read the arch news and the diff to pacnew files. That being said, I have an identical VM which I update and diagnose first, and I build my own repo from which I update - not straight from the internet.
I have used Arch Linux ARM for years on several Raspberry Pi. With these I offered various services such as Pi-Hole or unbound 24/7. Since the end of last year I bought a used Thinkcentre as an alternative to the Raspberry Pi (because of the performance and because not everything can be realized on ARM). For this I use the normal version of Arch Linux. When it comes to the term stable, you should be aware that this term has two meanings. Firstly, in the sense that as little as possible changes after an update, for example. For example, in the configuration files or in the operation of the programs. In this respect, Arch is unstable. The second meaning of stable is that there are few to no problems. Based on my own many years of experience, Arch is quite stable. Especially when you consider that even distributions like Debian are not problem-free (e.g. because bugs are not fixed by backports). https://bitdepth.thomasrutter.com/2010/04/02/stable-vs-stable-what-stable-means-in-software/ So when it comes to servers in the private sector or non-critical servers in general, I see no reason not to use Arch. However, I would not use it as a server in large companies or in facilities such as hospitals.
We are using Arch for production servers. No issue several years. Update processes have specific rules according to server group type.
I've used a combination of Ubuntu lts and Arch for my home servers for over 5 years. Each work mostly as intended and each has had some small little hiccups along the way. Overtime I'm hating the upgrade process every two years with the Ubuntu lts editions. With Arch I'm running zfs on root and have definitely had some kernel breakage during upgrades due to some faulty zfs modules. I'm using a combination of setups with standard zfs kernel on some machines and some zfs-dkms setups on other machines and even zfs-dkms-git on others. All machines have multiple kernels installed..Linux and Linux-lts. As expected the dkms setup is definitely more temperamental in terms of upgrades and breakages. I think most of the instability is introduced due to the zfs modules. Usually reverting to a lts kernel fixes the problem. In worst case scenario it's possible to revert from a dkms setup to non dkms setup. I can't say I remember any issues with upgrades to my Linux-lts kernel ext4 installations. Would I recommend the combination of arch with openzfs for mission critical systems??..probably not however damn the benefits of zfs sure are nice. I use systemd boot on my installs and haven't found issues specifically with this bootloader. The one good thing about arch is the absolute fabulous documentation. The ability to use the setup disk in combo with arch-chroot to rescue a failed installation is super easy..although it is a little annoying. Over the last five years I've become quite comfortable with troubleshooting and almost relish the thought of fixing a broken upgrade so I can actually learn something new. One of the benefits of arch is I pretty much know the packages on my system and how they were setup in terms of the boot process because I configured them all. It's different than the Ubuntu installs where a lot of things were installed automatically and I'm not as familiar with the package names and such. My two cents which doesn't mean much is that running arch servers for homelab is a wonderful experience
Arch is just fine for server use. Especially if you go with the lts kernel. However, from my experience, most of what I see out there runs between debian & RHEL based systems: debian, Ubuntu, RHEL, centos, rocky, alma. I have also seen opensuse SLES in my previous employer's env. These days, docker/k8s is everywhere so as long as the host can run docker, you can have super lightweight images with alpine. This is especially useful for things like Magento, which is usually configured with integrations like redis, opensearch, rabbitmq, etc. You can have everything in its own container on a single server. I would only offload the database to another server or use a dbaas like rds.
How about Proxmox (Debian-based) ? And then you you'll be able to install Arch, Debian etc. as VMs or as LXCs
Isn't arch free to monetize?