Arch Linux’s official repositories are deliberately curated: reviewed, built, and maintained by trusted developers. The AUR, the Arch User Repository, is the community’s answer to everything that curated approach leaves out: a vast collection of user-submitted build scripts covering software the official repos don’t carry, from obscure utilities to the newest builds of popular applications.

What the AUR actually is

The AUR is not a repository of pre-built packages the way the official repos are. It is a collection of PKGBUILD files, shell scripts that describe how to download, compile, and package a piece of software, submitted and maintained by ordinary Arch users. Installing something from the AUR means building it from source on your own machine using its PKGBUILD, not downloading a ready-made binary.

git clone https://aur.archlinux.org/some-package.git
cd some-package
cat PKGBUILD          # read it before doing anything else
makepkg -si            # build and install

makepkg is the underlying tool that reads a PKGBUILD and actually performs the build. -s automatically resolves and installs missing dependencies first, and -i installs the resulting package once the build finishes successfully.

Why the AUR requires more caution than official repos

Official repository packages are reviewed and maintained by trusted Arch developers before being made available. AUR packages are not reviewed by anyone official; literally any registered user can submit a PKGBUILD. Since a PKGBUILD is a shell script that runs with your build privileges, a malicious or simply careless one can do real damage, and there have been documented real cases of malicious AUR packages being published and later removed.

The standard, genuinely important practice: read the PKGBUILD before building and installing anything from the AUR, especially from an unfamiliar maintainer, rather than trusting it the way you might reasonably trust an official repository package.

cat PKGBUILD

Look specifically at the source= array (where it downloads from), the build() function (what commands actually run during compilation), and the package() function (what gets installed and where), the three sections most likely to reveal something suspicious if a package has been tampered with.

yay: automating the AUR workflow

Manually cloning a repository, reading the PKGBUILD, and running makepkg -si for every single AUR package gets tedious quickly. yay (and similar tools like paru) is an AUR helper that automates this workflow into pacman-like commands:

yay -S some-aur-package

yay -Ss keyword       # search both official repos and the AUR
yay -Syu               # update both official packages and installed AUR packages together
yay -Rns package-name    # remove a package (same syntax as pacman)

yay reduces friction significantly, but reviewing what it’s about to build is still good practice; most AUR helpers, including yay, will show you the PKGBUILD and prompt for confirmation before building, and it is worth actually reading it in that moment rather than reflexively confirming.

Installing yay itself

Since yay is itself an AUR package, it has to be bootstrapped manually the first time, the same way any AUR package would be installed without a helper already present:

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

This one-time manual step is unavoidable: yay cannot install itself before it already exists on the system, so every AUR helper has this same first-install bootstrap.

Judging whether a specific AUR package is trustworthy

The AUR website shows a vote count and last-updated date for every package, both useful informal signals. A package with many votes and recent updates is generally more actively maintained and more widely used, both of which correlate loosely with reliability. A package with very few votes, or one that has not been touched in years, deserves more scrutiny before installing, both for security and for the simple practical reason that it is more likely to be broken or incompatible with a current system.

The comments section on each AUR package’s page is also worth checking before installing; problems, workarounds, and compatibility issues are frequently reported and discussed there by other users who have already hit them.

Keeping AUR packages updated

yay -Syu

This updates both official repository packages and installed AUR packages in one pass. AUR packages, unlike official repo packages, sometimes require a rebuild after certain system-level changes (particularly major library version bumps), and yay -Syu handles detecting and rebuilding those automatically in most cases, though occasional manual intervention is more common for AUR packages than for official ones.

Frequently Asked Questions

What is the AUR and how is it different from the official Arch repositories?

The official Arch repositories (core, extra, and others) contain packages that are reviewed, built, and maintained by trusted Arch Linux developers and provided as ready-to-install pre-built binaries through pacman. The AUR (Arch User Repository) is a community-driven collection of build scripts, called PKGBUILDs, submitted and maintained by ordinary users rather than official Arch developers, and critically, these are build instructions, not pre-built binaries; installing something from the AUR means downloading its PKGBUILD and compiling it from source on your own machine, not downloading a vetted, ready-to-run package the way pacman does for official repo packages.

Is it safe to install packages from the AUR?

The AUR carries real risk that the official repositories do not, precisely because anyone can submit a package, and PKGBUILDs are not reviewed or vetted by Arch developers the way official repo packages are before being made available. A PKGBUILD is a shell script that runs with your privileges during the build process, so a malicious or careless one can do real damage, and there have been documented real-world cases of malicious packages appearing on the AUR. The standard practice, and a genuinely important one, is to read through a PKGBUILD before building and installing it, especially for anything from an unfamiliar or unverified maintainer, rather than trusting it blindly the way you might reasonably trust an official repository package.

What is yay and why do most people use it instead of building AUR packages manually?

yay is an AUR helper: a tool that automates the otherwise manual process of finding an AUR package, downloading its PKGBUILD, reviewing it, building it, and installing the result, wrapping the whole workflow into commands that feel similar to using pacman directly. Without a helper, installing an AUR package requires manually cloning its repository, inspecting the PKGBUILD, and running makepkg -si yourself for every single package, which is tedious enough that most Arch users adopt a helper like yay or a similar alternative such as paru specifically to reduce that friction, while ideally still reviewing what is being built before confirming the install.

How do I install yay itself, since it is not in the official repos?

yay is itself an AUR package, which means it has to be built manually the first time, the same way any AUR package would be without a helper already installed: sudo pacman -S —needed base-devel git, followed by git clone https://aur.archlinux.org/yay.git, then cd yay and makepkg -si. This one-time manual bootstrap is necessary specifically because yay cannot install itself before it exists on the system yet; every AUR helper has this same chicken-and-egg first-install step.

What does makepkg -si actually do?

makepkg is the underlying tool that actually builds a package from a PKGBUILD, and it is what both manual AUR installation and AUR helpers like yay ultimately call under the hood. -s automatically installs any missing build and runtime dependencies first (querying the official repos and, if needed, prompting to build additional AUR dependencies), and -i installs the resulting built package once the build completes successfully, rather than just leaving the built package file sitting in the current directory for you to install separately.

Can an AUR package break my system?

Yes, more so than an official repository package, since AUR packages are unreviewed by Arch developers and quality varies significantly between maintainers: some PKGBUILDs are well-maintained and reliable, others are outdated, broken, or interact poorly with system updates, particularly if the AUR package overlaps with or conflicts with files from an official package. It is good practice to check an AUR package’s comments section on the AUR website before installing, since problems and incompatibilities are frequently reported and discussed there by other users, and to be extra cautious with AUR packages that have not been updated recently or have very few votes, both of which are informal but useful signals of how actively and reliably a given package is maintained.