Running Arch Linux on a VPS: Pacman Essentials for Server Admins

Running Arch Linux on a VPS has a reputation for being high-maintenance. In practice, admins who run Arch servers well do very little that is exotic: they run full-system upgrades on a schedule, keep the package cache sane, and merge config updates when pacman hands them over. Most of that discipline lives in a handful of pacman commands, which is exactly what this post covers. If you are coming from apt or dnf, the mental model shifts slightly, and getting it right early prevents most of the horror stories you have heard about Arch.

Pacman's Mental Model: Two Databases

Everything pacman does is driven by two data sets. The sync databases, stored under /var/lib/pacman/sync, are downloaded copies of the repository indexes. The local database, under /var/lib/pacman/local, records every installed package, the files it owns, and what depends on it. Installing a package means resolving the dependency graph against the local database, downloading, verifying signatures against the Arch keyring, and committing the whole thing as one transaction. Most pacman mistakes come from breaking the assumption that the sync databases and the installed base agree with each other, which leads straight to the most famous trap in this package manager.

The Commands You Will Use Daily

# Sync databases and upgrade everything in one transaction
pacman -Syu

# Search the repos, inspect, then install with --needed
pacman -Ss nginx
pacman -Si nginx
pacman -S --needed nginx

# Query the local database
pacman -Q nginx
pacman -Ql nginx                   # files owned by the package
pacman -Qo /etc/nginx/nginx.conf   # which package owns this file

The --needed flag makes installs idempotent, which matters if you provision from scripts. The -Q family only reads the local database and never touches the network, so it is safe to use inside monitoring checks and cron jobs.

The -Sy Trap

The fastest way to break an Arch server is the partial upgrade. Because pacman assumes the sync databases match what is installed, refreshing the databases and then installing one package can pull in newer dependencies for that package while the rest of the system stays old. Libraries then disagree with each other, and dynamic linking errors follow. The rule is simple: there is no such thing as installing a package on Arch without upgrading the system.

# WRONG: refreshes the databases, then installs against a newer dep graph
pacman -Sy nginx

# RIGHT: upgrade everything, install your package in the same transaction
pacman -Syu nginx

If a full upgrade is inconvenient at this moment, the answer is to schedule it, not to work around it with -Sy. Package installs can usually wait a day; a half-upgraded system is a much bigger problem than a postponed nginx install.

Housekeeping: Cache, Orphans, Keyring

pacman keeps every downloaded archive in /var/cache/pacman/pkg. That cache is your local downgrade path when an update misbehaves, so trim it rather than emptying it. Orphaned dependencies accumulate quietly on long-lived servers, and a stale keyring is the classic cause of signature errors after months of neglect. The paccache utility ships in the pacman-contrib package, so install that first on a fresh box.

# Keep the two most recent versions of every package
paccache -rk2
# Also drop cached archives for packages that are no longer installed
paccache -ruk0

# Find and remove orphaned packages
pacman -Qtdq
pacman -Rns $(pacman -Qtdq)

# After months offline, or on signature errors: refresh the keyring first
pacman -Sy archlinux-keyring && pacman -Su

Holding Packages Back, Carefully

IgnorePkg exists for the rare case where you genuinely cannot take an update yet, such as a vendor kernel module that lags behind a new kernel series. Used sparingly it is a legitimate tool. Used casually it produces a system that quietly rots while everything around it moves.

# /etc/pacman.conf
[options]
IgnorePkg = linux linux-headers

Put a recurring reminder on any ignore list. A held package ages in place while its dependencies and the rest of the base system move on, and the eventual reintegration is harder than the upgrade you skipped.

Config Files: .pacnew and .pacsave

pacman never overwrites a config file you have modified. When upstream changes such a file, pacman writes the new version next to yours as .pacnew, and when a package stops shipping a file you have customized, your copy survives as .pacsave. Merging those files is the recurring maintenance task that keeps an Arch server from drifting into a system only you understand.

# List unmerged config updates under /etc
find /etc -name '*.pacnew' -o -name '*.pacsave'

# Interactive merge with vimdiff, sdiff, or plain diff
pacdiff

Takeaway

Treat every sync as a full upgrade, keep two or three package generations in the cache, remove orphans on a schedule, and merge .pacnew files the week they appear. Run that loop and an Arch server is uneventful, which is exactly what you want from infrastructure.

You can spin up a fresh Linux VPS on Netbay in under 60 seconds and practice this whole loop on a disposable Arch instance before you touch production — netbayhosts.in.