Getting yay onto a machine takes one makepkg run on Arch Linux, one pacman command on Manjaro and nothing at all on EndeavourOS, which ships it. The work that matters comes after the install: reviewing what an AUR package builds, keeping upgrades sane, and not running it as root.
This guide covers how to install yay, the AUR helper, on all three distros, then how to use yay day to day: searching, installing and removing AUR packages, full system upgrades, development packages, and cleanup. It also covers the new Lua configuration file and a hook that holds back freshly changed AUR packages, plus the errors we reproduced on the way. If you are still deciding between helpers, our yay vs paru comparison has the build times and memory numbers, and the AUR helper roundup lists the other options. The steps below ran in October 2026 on Arch Linux (kernel 7.2.8, pacman 7.1.0) with yay 13.0.1, and we checked the Manjaro and EndeavourOS repo packages in containers on the same host.
Install yay on Arch Linux
Start from a working base system. If you have not installed Arch yet, the archinstall walkthrough gets you there, and the post-install checklist covers the user and sudo setup yay expects. Arch does not carry yay in its official repos. Ask pacman for it and you get this:
error: target not found: yayyay lives in the AUR, so the first copy has to be built with makepkg. That needs git and the base-devel meta package. Install both first:
sudo pacman -S --needed git base-develThere are two AUR packages to choose from. yay-bin repackages the prebuilt release binary and needs no Go toolchain. yay compiles from source. Use yay-bin unless you have a reason to compile.
Clone it and build it as your normal user, never with sudo:
git clone https://aur.archlinux.org/yay-bin.git
cd yay-bin
makepkg -simakepkg verifies the checksum, packages the binary and hands it to pacman, which asks for your sudo password. On our VM the whole run took 3.6 seconds. Confirm the binary works:
yay --versionThe version line also shows which libalpm yay links against. That matters later, when pacman upgrades:
yay v13.0.1 - libalpm v16.0.1The makepkg run, trimmed to the key lines, looked like this:
Notice the second package, yay-bin-debug. The default /etc/makepkg.conf on Arch has debug in OPTIONS, so every makepkg build also produces a debug package. It is harmless, but pacman does not remove it with the main package, so name both when you uninstall.
Build yay from source instead
The source build works the same way with a different repo:
git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -siIt pulled in the Go compiler (226 MiB installed) and took 30 seconds on 4 vCPUs. The catch: makepkg leaves Go installed afterwards as an orphaned build dependency. Check for orphans:
pacman -QdtqGo is the only one listed:
goOnce yay works, yay -Yc removes it. That is covered in the upgrade section below.
Install yay on Manjaro
Manjaro packages yay in its own extra repo, so there is nothing to build. Update the system first, because Manjaro syncs from branch snapshots and a partial upgrade is the classic way to break it:
sudo pacman -SyuThen install it with pacman:
sudo pacman -S yayOn the stable branch the package came from Manjaro’s repo, built from the same upstream release as the Arch AUR package:
Repository : extra
Name : yay
Version : 13.0.1-1
Depends On : git pacman
Build Date : Fri Jun 19 21:51:11 2026That dependency list is short on purpose. The repo package does not pull in base-devel, and any AUR package that compiles code needs gcc, make and the rest of that group. Install it once with sudo pacman -S --needed base-devel. The AUR targets current Arch while Manjaro stable trails it by days or weeks, so an AUR package can occasionally want a library version Manjaro has not shipped yet. Our Manjaro vs EndeavourOS comparison goes into that branch model.
Check yay on EndeavourOS
EndeavourOS installs yay by default. It is part of the eos-base-group package list and comes from the [endeavouros] repo run by the distro, not from the AUR. Confirm where your copy comes from:
pacman -Si yayThe repository line names the EndeavourOS repo:
Repository : endeavouros
Name : yay
Version : 13.0.1-1
Depends On : pacman>6.1 git
Build Date : Sat Jun 20 11:46:50 2026Normal system upgrades keep it current, so leave it alone. Do not build yay-bin from the AUR on top of it. yay-bin declares Conflicts With: yay, and pacman will offer to replace the repo package with your local build, which then stops getting updates from the EndeavourOS repo.
Where each distro gets yay, side by side:
| Distro | Where yay comes from | Install command | Updated by |
|---|---|---|---|
| Arch Linux | AUR (yay-bin or yay) | makepkg -si in the cloned repo | yay itself (yay -Syu) |
| Manjaro | Manjaro extra repo | sudo pacman -S yay | pacman -Syu |
| EndeavourOS | [endeavouros] repo, preinstalled | none | pacman -Syu |
Install and remove AUR packages with yay
yay takes pacman’s flags and adds the AUR to them. Run it as your normal user. It calls sudo itself when pacman needs root. Search both the repos and the AUR at once. The output below is trimmed to three of the matches:
yay -Ss google-chromeAUR results carry the aur/ prefix, followed by votes, popularity and the age of the last change in brackets:
aur/chromedriver 154.0.8037.92-1 (+52 0.04) [2d2h]
Standalone server that implements the W3C WebDriver standard (for google-chrome)
aur/google-chrome-beta 156.0.8078.4-1 (+359 0.99) [1d14h]
The popular web browser by Google (Beta Channel)
aur/google-chrome-dev 156.0.8072.0-1 (+653 0.98) [4d9h]
The popular web browser by Google (Dev Channel)Read that age column. Recent yay releases added it, and a package changed hours ago deserves a closer look than one stable for months.
Run yay with only a search term and it prints a numbered menu instead:
yay google-chromeType the numbers to install, ranges like 1-3, or ^4 to exclude one:
2 aur/google-chrome-dev 156.0.8072.0-1 (+653 0.98) [4d10h]
The popular web browser by Google (Dev Channel)
1 aur/google-chrome 154.0.8037.92-1 (+2374 13.02) [2d10h]
The popular web browser by Google (Stable Channel)
==> Packages to install (eg: 1 2 3, 1-3 or ^4)When you already know the name, install it directly. Read the PKGBUILD first. The AUR is user content, and the PKGBUILD is the script that runs on your machine:
yay -Gp google-chromeIt prints the build script without touching your system. Then install:
yay -S google-chromeyay resolves the AUR and repo dependencies, then asks two questions before building:
AUR Explicit (1): google-chrome-154.0.8037.92-1
Sync Dependency (8): libxtst-1.2.5-1, gtk3-1:3.24.52-1, libxss-1.2.5-1, ttf-liberation-2.1.5-2, alsa-lib-1.2.16.1-1, nss-3.130-1, xdg-utils-1.2.1-2, libcups-2:2.4.19-1
==> Packages to cleanBuild?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)
==> Diffs to show?
==> [N]one [A]ll [Ab]ort [I]nstalled [No]tInstalled or (1 2 3, 1-3, ^4)The clean build question wipes the cached build directory first. The diffs question shows what changed in the PKGBUILD since you last built it. On a first install there is nothing to diff, so read the file with -Gp as shown above, including every URL in its source array. That first read is what matters most. The browser packages that shipped a remote access trojan in July 2025 were brand new uploads, and their PKGBUILDs pulled a “patches” source from a GitHub repo the attacker controlled. On upgrades, answer A and read the diff.
The Chrome install took 45 seconds, most of it the 136 MB download. List every package that did not come from a configured repo:
yay -QmOn our VM that was the browser and yay itself:
google-chrome 154.0.8037.92-1
yay 13.0.1-1
yay-debug 13.0.1-1Remove a package with its unneeded dependencies and saved config files:
yay -Rns google-chromeThat single command removed 95 packages and 922 MiB on our VM, because Chrome had pulled in the whole GTK and Mesa stack on a server image. Read the list before you confirm.
Upgrade the system with yay
One command upgrades repo and AUR packages together. Running yay with no arguments does the same thing:
yay -SyuWith everything current, it checks both sources and stops:
:: Synchronizing package databases...
core downloading...
extra downloading...
:: Searching AUR for updates...
:: Searching databases for updates...
there is nothing to doTo see pending AUR updates without installing anything, use yay -Qua. It exits with code 1 and prints nothing when there are none, which is handy in scripts.
Packages ending in -git build from a branch head, so their version only changes when you rebuild. yay can track the upstream commits, but it needs a baseline first. Generate the development package database once:
yay -Y --gendbAfter that, include them in upgrades with --devel:
yay -Syu --develTwo maintenance commands round this out. yay -Ps prints package counts, cache sizes and the ten biggest packages. yay -Yc removes orphaned dependencies:
yay -YcOn the VM where we built yay from source, it found the leftover Go compiler:
checking dependencies...
Packages (1) go-2:1.27.1-1
Total Removed Size: 226.43 MiB
:: Do you want to remove these packages? [Y/n]For the pacman side of upgrades, mirrors and partial-upgrade traps, keep the pacman cheat sheet handy. Slow syncs usually mean a bad mirror, and ranking mirrors by country fixes that.
Configure yay
yay keeps its settings in ~/.config/yay/config.json, and the documented way to change them is a flag plus --save. This catches people out: --save is not an operation. Run it alone and yay falls back to its default operation, a full -Syu:
yay --save --answerdiff None --answerclean None --removemakeIt saved the settings, then synced the databases and checked for upgrades:
:: Synchronizing package databases...
core downloading...
extra downloading...
:: Searching AUR for updates...
:: Searching databases for updates...
there is nothing to doPair it with -Y and yay saves the settings without doing anything else:
yay -Y --save --answerdiff None --answerclean None --removemakeWatch the flag syntax too. --answerdiff takes a value, but --removemake does not. Our first attempt was --removemake yes, and yay treated yes as a search term and opened a 274 entry menu of AUR packages matching it. Print the active settings to confirm what was saved:
yay -P -gThe relevant keys now read:
"answerclean": "None",
"answerdiff": "None",
"removemake": "yes",Skipping the diff menu is convenient. It also skips the review step from the install section, so only do it on machines where you check PKGBUILDs some other way.
Configure yay with init.lua
Recent yay releases added a Lua config file, init.lua. yay reads it from $XDG_CONFIG_HOME/yay/init.lua, then ~/.config/yay/init.lua. It overlays config.json, and command line flags still win over both. The option names use underscores and differ from the JSON keys. Create the file:
vim ~/.config/yay/init.luaThis is the file we ran. It sorts search results by votes, removes build dependencies after each build, and loads one hook module:
yay.opt.answer_clean = "None"
yay.opt.answer_diff = "None"
yay.opt.remove_make = "yes"
yay.opt.sort_by = "votes"
yay.opt.clean_after = true
require("recently_modified")yay validates every key at startup. A JSON name such as diffmenu instead of diff_menu stops it cold, which is better than a silently ignored setting:
-> init.lua: unknown yay.opt key: diffmenuThe full option list is in the yay Lua API documentation.
Hold back fresh AUR updates with a Lua hook
The other way a package goes bad is from the inside: an orphaned package adopted by a new maintainer, or a hijacked account pushing a poisoned update to something you already run. Bad packages tend to be reported and pulled within days (the July 2025 uploads were gone two days after they appeared), so a short delay on AUR upgrades buys time for the community to notice before your machine builds the change. yay’s UpgradeSelect hook can enforce that delay. The require("recently_modified") line above loads it from the same directory:
vim ~/.config/yay/recently_modified.luaThis is the upstream example from the yay repo, unchanged. It excludes any AUR upgrade whose package was modified in the last three days:
yay.create_autocmd("UpgradeSelect", {
desc = "skip recently modified AUR upgrades",
callback = function(event)
yay.log.info("pre-excluding AUR packages modified in the last 3 days")
local exclude = {}
local recent_cutoff = os.time() - (3 * 24 * 60 * 60)
for _, pkg in ipairs(event.data.upgrades) do
if pkg.repository == "aur" and pkg.last_modified >= recent_cutoff then
yay.log.warn("pre-excluding recently modified AUR package: ", pkg.name)
table.insert(exclude, pkg.name)
end
end
return { exclude = exclude, skip_menu = false }
end,
})To test it, we installed visual-studio-code-bin from the AUR commit before its latest update, which had landed two days earlier. yay -Syu saw the upgrade and skipped it:
Once the change is older than three days, the hook stops excluding it and the upgrade goes through. Two limits apply. The hook only covers upgrades, so a brand new package you install yourself gets no delay. It would not have held back the July 2025 packages, which were new uploads; reading the PKGBUILD is the defence there. It also holds back urgent security fixes for three days, so adjust the cutoff to your risk tolerance. The upstream repo also has a maintainer_change.lua example that warns when an AUR package changes hands, which is the other common way a package goes bad.
Fix common yay errors
We triggered each of these on the lab VM. They account for most of the yay questions in Arch forums.
==> ERROR: Cannot find the fakeroot binary.
makepkg ran without base-devel installed. On a minimal install the output was:
==> ERROR: Cannot find the debugedit binary required for including source files in debug packages.
==> ERROR: Cannot find the fakeroot binary.Install the group and run makepkg again: sudo pacman -S --needed git base-devel.
==> ERROR: Running makepkg as root is not allowed
This is sudo makepkg -si. makepkg refuses outright and exits with code 10:
==> ERROR: Running makepkg as root is not allowed as it can cause permanent,
catastrophic damage to your system.Run makepkg as your normal user. It calls sudo for the install step only. sudo yay is worse. It prints Avoid running yay as root/sudo., installs the repo dependencies as root, and when makepkg refuses to build, those dependencies stay behind as orphans. Run yay as your user too.
yay: error while loading shared libraries: libalpm.so.15
yay links against libalpm, the library behind pacman. When pacman moves to a new libalpm soname, an older yay binary stops starting. We reproduced it by running an older release binary on current Arch:
./yay_12.5.2_x86_64/yay: error while loading shared libraries: libalpm.so.15: cannot open shared object file: No such file or directoryyay cannot upgrade itself in this state, so rebuild it with makepkg. On Arch, repeat the yay-bin clone and makepkg -si steps from the install section with a fresh clone. That only helps once upstream has shipped a binary for the new libalpm. If the fresh yay-bin fails the same way, build the source yay package instead, which compiles against the libalpm you have installed. On Manjaro and EndeavourOS, sudo pacman -Syu brings a matching build from the distro repo.
error: target not found: yay
You ran sudo pacman -S yay on Arch, which does not package it. Build it from the AUR as shown at the top. On Manjaro the same error means the package database is stale, so run sudo pacman -Syu first.
Remove yay
yay is an ordinary package, so pacman removes it. List the installed yay packages first, because the name depends on how you installed it:
pacman -Qq | grep -E '^yay'A source build shows the main and debug packages:
yay
yay-debugRemove both. For a yay-bin install the names are yay-bin and yay-bin-debug:
sudo pacman -Rns yay yay-debugpacman does not touch your home directory. Delete the build cache and config yourself if you are done with yay for good:
rm -rf ~/.cache/yay ~/.config/yayAUR packages you installed stay on the system after yay is gone. pacman -Qm still lists them, and pacman removes them like any other package. They just stop receiving updates until you install an AUR helper again.
