AM: A Shell-Based Package Manager That Treats AppImages Like APT Treats DEBs

The Problem AM Solves: AppImages Without a Package Manager

AppImages are portable, but they have a discovery and lifecycle problem. You download a file, make it executable, and run it, but there is no central registry for updates, no clean way to remove it, and no standard place to put it. AM steps in as a package manager for these portable formats, mirroring what APT does for DEBs and DNF for RPMs. It is aimed at GNU/Linux users who run multiple AppImages and want a command-line tool to install, update, and remove them consistently. The README positions AM as a home for AppImages, giving them a package manager just like other formats have. The project uses a large database of Shell scripts, each dedicated to an app or a set of apps, inspired by the Arch User Repository. That database is the core of what makes AM different from a simple downloader.

How AM Works: Scripts, Directories, and an AUR-Helper Mindset

AM is a set of BASH scripts, compatible with ZSH, FISH, and most POSIX-compliant shells. It does not use a new packaging format like Flatpak or Snap. Instead, it orchestrates existing tools to download, extract, and integrate portable programs. The installation order, as stated in the README, is: create base directories and a removal script, download the package, create a version file and an update script, and optionally extract icons and .desktop files. That order shows the mechanism: AM does not just drop a binary; it builds the metadata needed for later updates and removal. The update mechanism relies on version files, which is why each app script must know how to fetch the current version. AM also supports sandboxing AppImages, though the README does not detail the sandboxing mechanism beyond listing it as a feature. The AUR-helper comparison is apt because AM can assemble apps on the fly, and it can use third-party databases, which you can replace with your own. The data flow is: you run a command, AM reads the app's script from its database, executes the script to download and prepare the package, then integrates it into the system.

Getting AM Running: Installation Paths and Dependencies

You can install AM system-wide or locally. The README lists three installation methods: the AM-installer script, which lets you choose between local and system-wide; a GIT method that only does system-wide; and a one-line command that also only does system-wide. The local variant is called AppMan, and it avoids the need for sudo or doas. System-wide installation requires root privileges, so you need sudo or doas. The CORE dependencies are coreutils, curl, grep, and sed. Most distributions pre-install coreutils, grep, and sed, but curl may be missing. If any CORE dependency is absent, AM will not work. OPTIONAL commands are needed for specific package formats. For example, 7z is required for .7z packages, tar for .tar packages, ar for .deb extraction, and file for determining file types. Checksum utilities (md5sum, sha1sum, sha256sum, sha512sum) are often in coreutils but may be absent on minimal systems. The README notes that many OPTIONAL commands are not pre-installed, so you must check which formats your target apps use. To see what a program does, you run `am -a {PROGRAM}` for a description and source contacts, or `am -d {PROGRAM}` to download and read the script on your desktop.

The AppMan Local Mode and Path Configuration

AppMan is the local installation variant of AM. It installs apps into your home directory, which means you do not need root privileges. This is a significant difference from system-wide mode, which integrates apps into the system and requires sudo or doas. The README includes a section on how to set the path to local apps, which is important because local binaries need to be on your PATH to run from anywhere. The README does not give the exact command for setting the path, but it implies that you configure it manually after installation. The existence of AppMan suggests a design choice: AM wants to serve both users who have root access and those who do not, such as on shared systems or in containers. The trade-off is that local mode may require more manual PATH management, while system-wide mode integrates more cleanly but demands privileges. The README also mentions that AM can integrate AppImages by drag/drop or install unlisted AppImages, which gives flexibility beyond the database.

A Genuine Limitation: AM Is Not Responsible for App Malfunctions

The README is blunt: 'AM is NOT responsible for the malfunction of individual apps!' That is a clear boundary. If an AppImage fails to run after installation, AM will not fix it. The problem is attributed to upstream developers or packagers. This is a real limitation because a package manager that cannot guarantee the software it installs works may frustrate users who expect a curated experience. AM is more like a delivery mechanism: it fetches and integrates, but it does not test or validate the apps. The README directs you to use `am -a {PROGRAM}` to get sources to contact maintainers, or `am -d {PROGRAM}` to download and read the script to trace the source safely. That is a workaround, but it puts the burden on the user. Another limitation is the dependency on OPTIONAL commands. Unlike Flatpak, which bundles its runtime, AM relies on the host to have tools like 7z or tar. On a minimal system, installing an app that requires 7z will fail unless you install it first. The README acknowledges this: 'AM has the drawback of having to adapt to the various platforms and packaging formats distributed portablely by upstream developers.'

Alternatives: Flatpak and the AUR Helper Comparison

The README itself compares AM to an AUR helper, which is a useful reference point. An AUR helper, like yay or paru, builds and installs packages from the Arch User Repository, relying on PKGBUILD scripts. AM uses a similar model: a database of Shell scripts, each dedicated to an app. The difference is that AUR helpers are specific to Arch Linux, while AM is distribution-agnostic as long as you have the core dependencies. A more direct alternative is Flatpak, which provides a sandboxed runtime and its own package format. Flatpak bundles dependencies and runs apps in an isolated environment, whereas AM integrates apps directly into the system and relies on the host's libraries. That is a fundamental difference in approach: Flatpak isolates, AM integrates. If you value sandboxing and reproducibility, Flatpak is a stronger choice. If you want to manage existing AppImages without converting them to another format, AM is more direct. The README does not mention Flatpak, but the comparison is implicit in its claim to be the default package manager for AppImages.

Maintenance and Upgrade Cost: What You Should Know

AM is under active development, with recent releases 10.4.1, 10.4, and 10.3, the latest pushed in August 2026. That suggests a regular release cadence, but the maintenance cost for you depends on the database quality. Since each app has a dedicated script, the database must be kept up to date when upstream apps change their download URLs or version schemes. If a script breaks, updates for that app may fail. The README includes a section on regression testing for developers, which indicates that the project has a test suite, but it is aimed at contributors, not end users. You can update all installed apps with a command, and you can integrate AM with Topgrade to update everything on your system, which is a nice touch. The license is GPL-3.0, which means you can modify and redistribute the scripts, but if you distribute a modified version, you must share it under the same license. That is a consideration if you plan to fork or embed AM in a product. The README also provides instructions for Linux distro maintainers, so AM is designed to be packaged, which could ease maintenance if your distro includes it. However, the README warns that you may need to install OPTIONAL commands, so budget for that during setup.

Editorial conclusion

Adopt AM if you manage many AppImages on GNU/Linux and want a command-line workflow that integrates them system-wide or locally, updates them all, and can even assemble them as an AUR helper. Do not adopt it if you expect it to fix broken apps; the README explicitly states that AM is not responsible for individual app malfunctions, and you will need to contact upstream maintainers. Before adopting, verify that your host has the CORE dependencies (coreutils, curl, grep, sed) and check which OPTIONAL commands (7z, tar, ar, file, checksum utilities) your target apps require, since many are not pre-installed. Also confirm whether you need sudo or doas for system-wide mode; the local AppMan variant avoids that. If you prefer a sandboxed, self-contained runtime that bundles its own dependencies, Flatpak is a different approach; AM is closer to an AUR helper that orchestrates whatever the host provides.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes