Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Do you consider Arch Linux suitable for server environment? Its rolling release model and simplicity seems to be a good thing, because once you installed it, you do not need to reinstall like the release model from other distros.

But that constant upgrading does not cause stability problems? Although it is bleeding edge, Arch Linux uses the most recent STABLE version of software.

share|improve this question
You may find helpful discussion and comments posted recently under the Arch as a web server thread on the arch-general mailing list. – mloskot Jun 19 '12 at 12:49

5 Answers 5

up vote 25 down vote accepted

Probably the biggest issue with Arch as a server operating system is that it's not clear where and when applications may break after an upgrade. More often than not, you have to keep up with what's going on in the wiki and on the forums before doing any sort of upgrade; with Debian and CentOS, you can well assured that any upgrades won't break any applications, since more often than not, the upgrades done on the STABLE branch will be security/bug fixes.

share|improve this answer
However, shouldn't you be testing your updates before rolling them out anyways? We are running a few Arch boxes in production, and testing updates every week or so on some internal machines. When everything is assured to be working, I roll out the updates. – Eric Coleman Feb 7 '11 at 22:46

Although i love arch, i wouldn't use it for production environment. First of all, in a production environment you need something stable and well tested. In addition, because it's quite stripped, you need to make custom scripts or setup things manually (It's sometimes good because you know exactly what is running in your system, but very bad because it takes too much time to configure it). Besides that, because it's not widely used in production environments, in case of a problem you won't find the support that you would find if you were using Debian or Fedora (Arch community is great, but to be honest, is not as large as Debian's or Fedora's)

To summarise, i think it's great for desktop use, but not for production environments

share|improve this answer

I would always suggest one of:

  • CentOS. It's a free RHEL clone, meaning you get a very long support cycle (7 years), during which you can get just security fixes and minor enhancements, so keeping the system patched is very, very easy. Also, lots of "commercial" software target RHEL, so they are easier to install on CentOS. Drawbacks: I prefer apt/dpkg to yum/rpm, not easy to get bleeding edge software running on it, somewhat spartan software selection

  • Ubuntu LTS. Actually I still haven't used it, but it also has a long support cycle and it's Debianish

  • Debian testing. Debian's my favourite distro, works really well and it has a stupidly huge package selection which is very-well put together. It's somewhat more time-consuming to keep patched, but it's easier to install software (i.e. there's more stuff readily packaged).

I would suggest considering pros to using Arch Linux to one of those three and see if it's worth it.

share|improve this answer
You would use Debian testing on a production server? That makes no sense to me. How often are you fixing things that break during updates? – Jason Berg Aug 22 '10 at 18:14
@Jason: More worryingly, while Debian now has official security support for testing, it's not as good as for stable or unstable, since a security update for testing has a reduced but nonzero quarantine time and can be delayed due to unmet dependencies. – Gilles Aug 22 '10 at 21:37
I turn to testing when I want to run somewhat recent software (i.e. getting Rails apps running on CentOS is a bit irksome- but quite easy on Debian Testing...). I use debsecan to pull just security updates and it's normally quite stable. Were I use it for hardcore production, I'd like to do extensive testing before rolling out updates on testing boxes. Of course, I should also do that in CentOS boxes :-p – alex Aug 23 '10 at 18:08
“[Debian] is somewhat more time-consuming to keep patched” − Why would it be harder to keep up-to-date and patched? Just like CentOS updates, it is just a apt-get upgrade. Maybe I'm missing something… – Léo Lam May 23 at 18:52
I don't really see how this answer addresses the question, which is "is Arch Linux suitable for a server environment?". Suggesting three other distros and then suggesting the reader to do their own comparison to Arch Linux, doesn't constitute an answer. – Jon Bentley Aug 12 at 23:26



  • really minimal system out of the box, great for performance especially on low-end machines/VPS. No unneeded services - compared to CentOS 7 which started several VM-related services that weren't even applicable to me as I was running on bare-metal.

  • up to date software and big repositories; I lost quite a bit of time with CentOS when something wasn't in the repos and I was forced to either compile it from source or install third-party RPMs/repos, and then end up in dependency hell because these third-party RPMs were conflicting with upgrades from official repos.

  • systemd, though other distributions (even Ubuntu) are switching to it so it's less of a pro but something to be expected from any decent distro.

  • network configuration tools that makes sense. No desktop-grade Networkmanager nor firewalld (looking at CentOS/RHEL).

  • package manager that does just what it says on the tin. The package manager won't try to "help" you by automatically configuring or starting the service you just installed (looking at Ubuntu/Debian). It's also fast, better than yum, and maybe a tiny bit faster than apt-get.

  • installation process that doesn't force you to use any defaults and offers lots of room for customization - compare that to CentOS/RHEL which forces you to use LVM and swap, something not always needed (almost never in my case actually)

  • /usr/bin/python is actually the latest Python 3, not the prehistoric Python 2.7. That's always a problem for me with most other distributions, and you can't easily change that either (at least not system-wide) as it will break many apps who rely on it.


  • some upgrades require manual intervention and can break. I recommend having a replica of your production environment in VMs and testing the upgrades there before rolling them out on the real servers.

  • no default working configurations. Bad for people who just want to run apt-get and install their default insecure LAMP stack to deploy their crappy vulnerable PHP app and pollute the internet. Of course, that's actually an advantage for serious people as it forces you to review the config files before starting the service.

  • no SELinux support. There is GRSecurity and its RBAC, but you'll need some time to get used to it and fine-tune it.

I would disagree on the fact that you get less support. Sure, that's true. Is that a disadvantage ? No in my opinion. There's very little in Arch that could break and will require support from someone familiar with Arch. Usually if you need support you'll need it for a particular software, in which case you'd ask its developers and the fact that you're running Arch becomes irrelevant.

For me, using Arch is way easier and less time-consuming than using CentOS and its Networkmanager, firewalld and other unneeded services (they can be disabled, but that's already wasted time). Plus, I know every single service that runs on the system because I would've installed it, no sneaky software that nags me about a bug and wants to phone home even though I just installed the system.

share|improve this answer

I would say yes, with the caveat you should never just run pacman -Syu on a production server and keep diff-image backups of the system drive that can be rolled over the filesystem in case of breakage.

MUCH more usable (far less breakage webs) than Debian testing / sid. If you want cutting edge packages and a minimal install, Arch is the best distro for that but requires a lot of comfort with manual management.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.