# ivan-hc/AM: an AUR-style package manager for AppImages > AM (AppMan) is a set of Bash scripts that installs, sandboxes, updates and removes portable GNU/Linux apps from a curated database of per-app shell scripts. It is for people who already use AppImages and want APT-like bookkeeping around them, not a replacement for their distribution's package manager. **ivan-hc/AM** — AppImage Package Manager: AppImage sandboxing, local and system installation, update all AppImages, an extensible database of AppImages and portable apps, lists for AppImages and other GNU/Linux binaries, integrate AppImages by drag/drop or install unlisted AppImages, conversion of old AppImage types... and more! Manage AppImages like never before! - Repository: https://github.com/ivan-hc/AM - Website: https://portable-linux-apps.github.io - Stars: 1,379 · Forks: 132 - Language: Shell - License: GPL-3.0 - Published: 2026-08-08 · Updated: 2026-08-18 · Language: en - Canonical page: https://hysenlabs.com/projects/ivan-hc-am ## The gap AM fills between AppImage and APT An AppImage is a single executable file. Nothing tracks where it came from, which version it is, whether a newer one exists, or how to remove it cleanly along with the icons and .desktop entry it dropped into your home directory. AM exists to close that gap. The README describes it as a set of scripts and modules for installing, updating and managing AppImage packages and other portable formats, in the same way that APT manages DEBs and DNF manages RPMs. The audience is narrow and specific: GNU/Linux users who already prefer portable apps over distribution packages, and who want command-line bookkeeping over manual downloads. AM targets that group rather than trying to convert people who are happy with their distro's repositories. The README frames the goal as becoming the default package manager for AppImage packages, giving them a home to stay. ## A database of shell scripts, not a binary repository The mechanism is closer to the Arch User Repository than to a conventional package index. Every installable program has a dedicated shell script in the database, and AM runs that script to perform the installation. The README states the order of operations explicitly: creation of the base directories and the removal script, download of the package, creation of the version file and the update script, and possibly extraction of the icons and .desktop files. That sequence explains what AM actually leaves behind on disk. A removal script and a version file are written before anything is downloaded, which is what makes a later uninstall and an update check possible at all. The update script records where to look for a newer release. Icons and desktop entries are extracted only when the package carries them. Because entries are scripts, the database can absorb formats beyond .AppImage. The README lists .7z, .deb, .tar and .tar.xz handling among the optional commands, and describes AM as more like an AUR helper that may require extra tools for packaging formats other than .AppImage. That flexibility is also the weak point: an entry that shells out to extract a .deb is doing work a native package manager would do with metadata. ## Installing AM and installing your first app The README gives three installation routes. The AM-INSTALLER script lets you choose between local and system-wide installation, the GIT route is system-wide only, and there is a one-line command that is also system-wide only. The project also documents a manual AppMan installation for the local variant. Before any of that, check the CORE dependencies. The README lists coreutils, curl, grep and sed as required, and notes that curl is not present in all distributions. If you install the system-wide AM rather than the local AppMan, the README states you need sudo or doas for root privileges. Once installed, the first useful command is a lookup rather than an install. The README gives this example for reading about a program and finding its sources: ```bash am -a {PROGRAM} ``` You should see the description of the program and the sources to contact its maintainers. If you want to inspect the install logic before trusting it, the README documents a second command that downloads the script to your desktop: ```bash am -d {PROGRAM} ``` That writes the per-app script somewhere you can read it, which is the closest thing to an audit step the project offers. Installing locally instead of system-wide uses the --user flag, and the README points to a separate section on setting the path to local apps if the default does not suit you. Updating installed apps and listing what is installed are separate commands covered in the options section of the README; the project also documents integration with Topgrade for updating everything in one pass. ## Sandboxing, snapshots and the libfuse2 problem Three features sit outside the plain install-and-remove loop. The first is sandboxing: the README lists sandbox AppImages as a headline capability, and the sample directory contains a sandbox.gif demonstrating it. The README does not spell out the sandboxing implementation in the excerpt available, so treat the mechanism as documented by demonstration rather than by specification. The second is snapshot creation and restore, again listed as a capability with a backup-overwrite.gif in the sample directory. Snapshots matter here because AM installs into system directories by default and writes removal scripts alongside; a snapshot is the escape hatch if a batch update goes wrong. The third is getting rid of libfuse2. Older AppImages link against FUSE 2, which many current distributions no longer ship. The README lists this as a feature and the sample directory contains nolibfuse.gif. This is a real friction point for AppImage users generally, and AM addressing it directly is more useful than another wrapper script that ignores it. ## Where AM is the wrong tool The README is unusually blunt about scope: AM is not responsible for the malfunction of individual apps, and that is a problem of those who develop or package them upstream. Read that as a design boundary, not modesty. If an AppImage crashes on launch, AM cannot help you, and the documented remedy is to use am -a to find the upstream maintainers. There is a second boundary in the dependency table. AM itself needs only four core commands, but the apps you install may need 7z, ar, tar, unxz, xz, xzcat, file, column, du, checksum utilities or notify-send, and the README warns that many of these are not pre-installed and that some package names vary between distributions. On a minimal system you can end up installing a stack of extraction tools before the first app works. Finally, if your distribution already packages the application you want, AM adds a parallel update path with its own version files. Two package managers tracking the same software is a maintenance cost, not a feature. ## How AM differs from AppImageUpdate and Flatpak AppImageUpdate is the closest comparison and the difference is architectural. AppImageUpdate relies on embedded update information inside the AppImage itself, so it can only update files that were built with that metadata, and it does not install anything. AM takes the opposite approach: it keeps its own version file and update script per application, so it can track releases even when the AppImage carries no embedded update information, and it also handles installation, menu integration and removal. The trade-off is that AM's knowledge lives in a shell script maintained by the database, not in the artifact. Flatpak differs at a deeper level. Flatpak defines its own packaging format and runtime, so applications are built for it. AM does not define a format at all; it adapts to whatever upstream developers publish, which is why the README compares it to an AUR helper and why the optional dependency list is long. Flatpak gives you a consistent runtime and a single update mechanism at the cost of applications having to be repackaged. AM gives you upstream artifacts as published, at the cost of per-app variability. ## Licence, maintenance and upgrade cost AM is licensed GPL-3.0. That matters if you plan to redistribute a modified copy or bundle it into a distribution image; the licence text in the repository is the authoritative source and this is not legal advice. The last push to the main branch was on 2026-08-15, the same day as the 10.4.1 release. The two preceding releases, 10.4 and 10.3, are dated 2026-08-13 and 2026-06-29. The repository is not archived. The release cadence in that window is uneven rather than steady, which is normal for a project driven by upstream packaging changes. The upgrade cost is low for the tool and potentially higher for the database. AM is a Bash script, so updating it means replacing a script; there is no compiled artifact to rebuild. The per-app scripts are the part that needs attention, because upstream download URLs and archive formats change without warning. The README's own guidance, am -d {PROGRAM} to download and read the script, is the practical way to check whether a specific entry still matches what upstream publishes. ## Conclusion Adopt AM if you already run AppImages and want a single command to install, sandbox, snapshot and update them, and if you accept that a database entry is only as good as the upstream packaging it wraps. Do not adopt it as a substitute for APT, DNF or Pacman, and do not expect it to fix an app that is broken upstream, because the README says explicitly that AM is not responsible for the malfunction of individual apps. Before installing, verify that curl, grep and sed are present, check whether you need sudo or doas for the system-wide mode, and look up the specific program with am -a {PROGRAM} to see who actually packages it. ## FAQ ### Do I need to install AppImage to use AM? No. AM is a Bash script that manages AppImage files and other portable formats; you install AM itself, then use it to install the applications. The README lists curl, grep, sed and coreutils as the core dependencies AM needs on the host. ### Why won't my AppImage run, and can AM fix it? The README states that AM is not responsible for the malfunction of individual apps and that this is a problem of those who develop or package them upstream. It suggests using am -a {PROGRAM} to view the description and get the sources to contact the program maintainers. ### Is AppImage like an .exe file? AM does not make that comparison. What the README does say is that AppImage differs from APT, DNF, Pacman, Snap and Flatpak, which each have their own packaging formats, and that AM is more like an AUR helper because it may need additional commands to handle formats beyond .AppImage. ## Sources - [Official documentation](https://portable-linux-apps.github.io) - [Official README](https://github.com/ivan-hc/AM#readme) - [Project repository](https://github.com/ivan-hc/AM) - [Release notes](https://github.com/ivan-hc/AM/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ivan-hc-am