Arch Linux on a VPS: Minimal Install, AUR, and Rolling Updates

Arch Linux on a VPS in 2026 is rarely an installer dance; standard images and scripted installers reach a bootable base in minutes, and the real discipline lives after first boot. Keep the base deliberately small, add the AUR only with rules, and treat rolling updates as a scheduled activity rather than an impulse. This post walks the minimal path from a fresh Arch instance to a server you can trust: what the base really contains, how to hold it lean, when the Arch User Repository is worth the risk, and the update cadence that keeps rolling from becoming roulette.

The Base Is Already Minimal, Keep It That Way

Arch's base install includes a kernel, an init system, little else, and the critical work on the machine is refusing to grow it. The explicit-package list is the inventory that tells the truth: a small server is under a hundred packages, and every addition is a decision to justify.

pacman -Qqe | wc -l
pacman -Qqe          # exactly what you asked for, nothing transitive
pacman -Qtdq         # orphans you did not mean to keep

Run the first and third commands on a schedule. Orphans accumulate quietly on long-lived machines, and -Rns keeps the dependency graph honest.

Users, SSH, and the Boot Convention

The stock OpenSSH defaults on an Arch base still permit password authentication, so the first boot is the right moment to set the policy. Create a wheel user, harden the daemon with a drop-in, and make sure the box only ever answers to keys.

useradd -m -G wheel deploy
passwd deploy
echo 'deploy ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers.d/deploy
chmod 0400 /etc/sudoers.d/deploy

# /etc/ssh/sshd_config.d/99-hardening.conf
PermitRootLogin no
PasswordAuthentication no
AuthorizedKeysFile .ssh/authorized_keys

sudo sshd -t && sudo systemctl enable --now sshd

The sshd -t validation runs before the daemon starts, so a syntax error cannot strand you outside a locked box.

The AUR: Power With a License Model

The Arch User Repository is a collection of build recipes rather than binaries: PKGBUILD files that describe where source comes from, how to verify it, and how to build it. Every package you install from it is a small piece of code you are choosing to execute with root privileges, which is the entire security model in one sentence: never build an AUR package you have not read, and never build one you could not audit. paru and yay are the common helpers; both present the PKGBUILD before building.

pacman -S --needed git base-devel
git clone https://aur.archlinux.org/paru.git && cd paru
makepkg -si

Rolling Updates With a Cadence

The system stays coherent if updates stay whole: sync and upgrade in the same transaction, merge .pacnew configuration updates before the next cycle, and reboot when the kernel changed. Scheduling is the discipline that makes rolling boring.

pacman -Syu
pacdiff
pacman -Qtdq
pacman -Rns $(pacman -Qtdq)

If a server skips more than a couple of monthly windows, the answer is a fresh base replaying from the package list, not a heroic mega-upgrade. Providers snapshots make that cheap, which is what makes the rebuild-instead-of-rescue model genuinely practical on Arch.

Takeaway

Arch on a VPS is a solveable problem with three rules: never let the base grow silently, read every AUR PKGBUILD you build, and upgrade the whole system on a schedule. With those rules the box stays small, audited, and current.

You can boot an Arch VPS on Netbay in under 60 seconds, add the base packages in minutes, and form the update cadence on a disposable machine — netbayhosts.in.