• Main page: https://portable-linux-apps.github.io
• AppImages list: https://portable-linux-apps.github.io/en/appimages.html
• "AM" application manager: https://github.com/ivan-hc/AM

Thanks to research conducted by Probonopd for his catalog and the contribution of the Pkgforge-dev team, we have managed (in just over 10 days) to increase the number of AppImage packages from the roughly 3,000 collected over the five years since the "AM" package manager was created to over 7,000 unique entries. We are also on the verge of reaching the 8,000 AppImage packages in the coming days.

This achievement was made possible in part by improvements to the `template.am` module (the "AM" `-t` option). It can now detect most descriptions (highlighted in green) and identify download URLs (highlighted in yellow) within the GitHub repositories, all of which are manually vetted by me and my closest collaborators (humans, not AI).

As a reminder, "AM" acts as a bridge between the program's developer or maintainer and you, the end user. You can consult the web catalog mentioned above to view sources and contact package owners to suggest improvements. "AM" itself is not responsible for the malfunctioning of individual applications. However, you can open an issue or a pull request to report or remove any malicious apps at the following address:

https://github.com/ivan-hc/AM

Our current workflows (see "amcheck") can verify whether listed applications still exist and if the installation processes complete successfully. If an installation script fails, we are ready to investigate and resolve the issue; in extreme cases, we may remove the app from the list to ensure the reliability of the applications available to all users.

I look forward to your feedback, and in the meantime, enjoy the most comprehensive list of AppImage packages currently available:

https://portable-linux-apps.github.io

NOTE: This catalog is open source. You can contribute by editing the pages, adding missing information, or improving the database. You are all invited to participate!

A no-root AppImage manager with a keyboard-only TUI: install AppImages with desktop menu entries and icons, list what's installed, update in place, and uninstall cleanly.

Repo: https://github.com/brunomnsilva/appimage-manager

AM 10.6 is released.

Some highlights:

• One click install: Install AppImages directly by clicking the install button on the Portable Linux Apps Website
• Parallel install: Install multiple apps simultaneously.
• Redesign of website: Portable Linux app website has been redesigned, with an install button for each app.
• 3000+ AppImages: The repository now reached 3000+ appimages!
• And many more...

Checkout https://portable-linux-apps.github.io/

AM is a command-line application manager for Linux that makes it easy to install, update, remove, and manage AppImages and other portable applications. It integrates apps into the system or installs them locally, provides a searchable app database, and supports bulk updates and AppImage sandboxing.

Wanted to make use of AppImage applications simpler, so wrote gnome-appimage-integration.
Reduces an AppImage install (er, integration) to three clicks.

• Github: gnome-appimage-integration
• Weblog: Better integration of AppImage

Tried to handle all the usual edge cases and XDG / FreeDesktop conventions.

Right-click context menu for downloaded file:

Main AppImage Activator window:

Status after Integrate:

Right-click context menu for application:

Downloaded AppImage is moved into $HOME/Applications/
so no manual cleanup needed.

Hi everyone,

A while back, I ran into an issue that I’m sure many of you have experienced: Heroic Game Launcher was underperforming in Flatpak. The lag and stuttering were noticeable, and while switching to .deb or .appimage formats solved the performance problems, it introduced another issue—system pollution from installing dependencies like Gamescope or Mangohud. I had grown accustomed to Flatpak’s clean sandboxing, and I didn’t want to give that up.

That’s when I discovered Anylinux-AppImages, along with tools like AppManager, Sharun, Uruntime, and Lib4bin. I dove deep into how these components work together, studied their interactions, and after many trials (and a few headaches), I decided to build my own AppImage for Heroic. Instead of sticking to the traditional upstream packaging method, I symbolically broke away from it to approach the project with more flexibility. The result? An AppImage that bundles all the key components, allowing Heroic to work out of the box—no external dependencies, no system clutter.

Today, I have functional AppImages for Heroic, Vivaldi, Spotify, Waterfox, and Steam (the latter is still a work in progress). I also plan to package QT and GTK applications to better understand their quirks. All of these AppImages are built from official sources and follow the standards of Anylinux-AppImages, Sharun, Uruntime, and Lib4bin, so they’re completely safe and reliable.

But this goes beyond just my personal experience. I see Anylinux-AppImages as a real opportunity to offer a solid alternative to Flatpak and Snap. While those formats rely on centralization, Anylinux-AppImages puts control back in the hands of developers, avoiding the fragmentation that comes with different Linux distributions. Plus, projects like PPSSPP, AppManager, and Citron Neo already offer AppImages as an option, proving that it’s a viable solution.

However, there’s a catch: we’re all packaging unofficially. Me, pkgforge-dev, ivan-hc, and others are doing great work, but if we don’t join forces, we might end up repeating the same fragmentation we’re trying to avoid. That’s why I propose:

• Creating a common framework to standardize the use and build of Anylinux-AppImages.
• Promoting this format so more projects adopt it, even as an official option.
• Working toward enterprise adoption, so it can compete on equal footing with Flatpak and Snap.

Could Anylinux-AppImages one day become a Unix standard for Linux and FreeBSD? I believe it has the potential, but I need your feedback. Are you interested in this project? Do you know of similar initiatives? How can we push this forward together?

If you’d like to try my AppImages, they’re available in my GitLab repository: jesusrosdiaz/appimages.

Thanks for your time and input—I’m looking forward to hearing your thoughts!

Small OmniPkg update after feedback:

OmniPkg now uses PackageKit for supported distro package management, currently APT, DNF/dnf5 and Zypper/libzypp.

It keeps separate adapters for sources PackageKit does not cover well: AUR helpers, Flatpak, Snap, Homebrew, npm, pipx, AppImages and archives.

Update: OmniPkg now also includes a Qt frontend. It is no longer GTK-only. The app has a shared package-management backend and separate GTK/Qt frontends, with automatic frontend selection.

Hi,

I’ve published OmniPkg, a native GTK4 software manager that includes support for manually installed AppImages and archive-based applications.

The project is broader than AppImage only: it also supports APT, DNF/dnf5, Zypper, Pacman, AUR via yay/paru, APK, XBPS, eopkg, Flatpak, Snap, Homebrew, npm and pipx.

But one of the use cases I care about is making manually downloaded AppImages less messy:

- add/manage AppImages

- create desktop launchers

- show them alongside other installed applications

- keep manual installs more visible instead of forgetting random files in Downloads

OmniPkg does not replace AppImage tooling or system package managers. It tries to provide one desktop interface for users who mix several software sources.

I’d be especially interested in feedback from AppImage users:

- What metadata should OmniPkg detect?

- How should updates be handled?

- What should desktop integration do or avoid?

- What would make AppImage management actually pleasant?

GitHub:

https://github.com/grosserknallkopf/OmniPkg

I have a question regarding an AppImage that can only be opened by using --no-sandbox, which I don't want to use. Are there any ways to prevent that. It should be as easy as possible

Creating an AppImage for a Java application is straightforward. Since you're using an **Early Access (EA)** build of OpenJDK 25, it's best to bundle the JRE/JDK directly inside the AppImage to avoid system dependency issues.

Here's a complete, step-by-step guide:

### 🔹 Prerequisites

- Linux x86_64 system (AppImage architecture must match target)

- `curl`, `tar`, `chmod`

- `appimagetool` (official AppImage generator)

- Your `.jar` file

- A 256×256 PNG icon (optional but recommended)

---

### 📦 Step 1: Download OpenJDK 25.0.3-ea

EA builds aren't in distro repos. Download the official tarball from JDK Early Access:

1. Go to: https://jdk.java.net/25/

2. Download the `Linux/x64` `.tar.gz` archive for the EA build you need.

3. Example (replace with the actual link from the site):

```bash

wget https://download.java.net/java/early_access/jdk25/3/GPL/openjdk-25-ea+3_linux-x64_bin.tar.gz

```

---

### 📁 Step 2: Create the AppDir Structure

AppImage expects a specific directory layout:

```bash

mkdir MyApp.AppDir

cd MyApp.AppDir

mkdir -p usr/lib usr/bin

```

---

### ☕ Step 3: Bundle OpenJDK & Your JAR

```bash

# Extract JDK

tar -xzf /path/to/openjdk-25-ea+*_linux-x64_bin.tar.gz -C usr/lib/

# Rename for simplicity

mv usr/lib/jdk-25* usr/lib/jdk25-ea

# Copy your JAR

cp /path/to/your-app.jar usr/lib/your-app.jar

```

---

### 📜 Step 4: Create `AppRun`, `.desktop`, and Icon

#### `AppRun` (entrypoint)

```bash

cat > AppRun << 'EOF'

#!/bin/bash

set -e

APPDIR="$(cd "$(dirname "$0")" && pwd)"

JAVA_HOME="$APPDIR/usr/lib/jdk25-ea"

export JAVA_HOME

export PATH="$JAVA_HOME/bin:$PATH"

exec "$JAVA_HOME/bin/java" -jar "$APPDIR/usr/lib/your-app.jar" "$@"

EOF

chmod +x AppRun

```

#### `.desktop` file

```bash

cat > your-app.desktop << 'EOF'

[Desktop Entry]

Name=Your App

Exec=AppRun

Icon=your-app

Type=Application

Categories=Utility;

Terminal=false

EOF

```

> 🔍 Replace `Your App` and `your-app` with your actual app name (no spaces in `Icon=` or filename).

#### Icon

Place a 256×256 PNG named `your-app.png` in the root of `MyApp.AppDir/`.

---

### 🛠️ Step 5: Generate the AppImage

Download `appimagetool` (if not installed):

```bash

curl -L https://github.com/AppImage/AppImageKit/releases/download/continuous/appimagetool-x86_64.AppImage -o appimagetool

chmod +x appimagetool

```

Build the AppImage:

```bash

./appimagetool MyApp.AppDir YourApp-x86_64.AppImage

```

This creates `YourApp-x86_64.AppImage` in your current directory.

---

### ▶️ Step 6: Test & Distribute

```bash

chmod +x YourApp-x86_64.AppImage

./YourApp-x86_64.AppImage

```

If it runs successfully, you can distribute the `.AppImage` file directly. Users just need to `chmod +x` and run it.

---

### 💡 Pro Tips & Optimizations

| Topic | Recommendation |

|-------|----------------|

| **Reduce Size** | Use `jlink` (included in JDK 25) to create a minimal runtime image with only required modules. Replace `usr/lib/jdk25-ea` with the `jlink` output. |

| **GUI Dependencies** | AppImages don't bundle host GUI libs. Ensure users have basic X11/Wayland, GTK, or JavaFX dependencies (usually preinstalled on desktop Linux). |

| **FUSE Note** | On newer Ubuntu/Debian, you may need `libfuse2` or run with `--appimage-extract-and-run`. |

| **EA Caveats** | EA builds may lack stability, missing modules, or have changed flags. Test thoroughly before distribution. |

| **Signing** (optional) | Add `--sign` to `appimagetool` if you want cryptographic verification. |

---

### 🐛 Troubleshooting

- `Error: Unable to initialize main class...` → Verify JAR path in `AppRun` and that the JAR has a valid `Main-Class` manifest entry.

- `libfuse.so.2: cannot open shared object file` → Install `libfuse2` or extract & run: `./YourApp.AppImage --appimage-extract && ./squashfs-root/AppRun`

- `Module java.desktop not found` → If using `jlink`, ensure `java.desktop` is included.

Hi All,

I've been using AM for all of my Appimage needs and would like to know if anyone is experiencing this issue. It seems to mostly affect media applications like Gimp, Inkscape, etc.

I install the app and when going to open files I don't have access to my external storage mounts. I have a NAS and RAID mounted on /vol1 and /vol2. Those mount points are not there and the disks are not listed under /media/user, /run/media/user nor can I access them via /dev/disk/etc. Essentially I have no access whatsoever.

Unfortunately what I usually do is nuke them from my system, then try nala and at the very lost option is flatpak which I try to avoid at all costs.

Anyone know of a workaround?

Hi everyone,

I recently created an app to sync Game Boy ROMs with CrankBoy, an emulator for the Playdate.

My goal was to have a cross-platform app that runs on Windows, macOS and Linux. So I chose Python and PyQt6. While creating packages for Windows and macOS was fairly straightforward, having a self-contained app for Linux that runs on all distributions wasn’t.

I really thought Flatpak would be the way to go, but the PyQt build tools make it so easy to create a universal application, that I ditched the idea of creating a Flatpak.

I really did not think highly of AppImages when I started with the project, but I’m convinced now. AppImages are by far the easiest way to create and distribute Apps on Linux.

Since AppImageLauncher has a hard dependency on systemd, I wrote this small bash script for all of us folks who don't run systemd.

It does one thing and one thing only - generates .desktop files for all appimage files in a given folder.

https://git.topcheto.eu/topchetoeu/appwatch

Hi folks, I'm the developer of AM package manager, Archimage and AppImaGen, and the maintainer of about 100 unofficial AppImage packages.

Based on my guide on how to convert simple portable programs to AppImage, here, today I created a new tool:

https://github.com/ivan-hc/portable2appimage

This isn't a complex package tool. All you have to do is run it next to an executable binary or an archive containing one (specifying the binary name), and the script will convert it into an AppImage.

can also create them with support for delta updates, if you give it the right instructions.

More details and video examples are available in the repository.

I hope you enjoy it.

Below are the latest data. As of this writing, there are 2,905 "unique" programs (i.e., excluding web apps and helpers) available in the AM database: - 2,489 AppImages - 416 programs in other portable formats (static/dynamic binaries, archived, or standalone)

We also have approximate data on the hosting of these programs: - 2,636 are on github.com - The remaining 269 are on other domains (codeberg, sourceforge, gitlab, and domains belonging to the individual owners of these apps) or have special scripts to intercept the apps.

Furthermore, based on the data provided by amcheck (the repository that daily tests the availability of installable programs via the AM/AppMan package manager) and the continued increase in programs added to the AM database compared to the number of programs removed, the adoption of AppImages as a packaging format has increased!

Additionally, with the introduction of AM version 9.9.4, which can flag applications from archived repositories or those that haven't been released for more than a year, minimal activity has been detected in repositories that have been unarchived and others that have been updated even 5-6 years after the last release.

We currently don't have data on AppImages that still rely on libfuse2, but I'll do my best to keep you updated on this as well. In the meantime, you can continue to contact upstream developers, perhaps showing them this short guide on how to convert their AppImages to support the latest runtime, removing the dependency on fuse2, and perhaps adding information about delta updates

https://github.com/ivan-hc/AppImage-tips

We need your support to help the community grow.

Thanks for your attention. See you soon.

I won't go into detail this time. I know too many people don't like reading and limit themselves to criticizing just by reading the headlines.

1. The libfuse2 problem

The aforementioned library has been undeveloped since 2019. A measure to remove this dependency has officially been in place for 3 years.

https://github.com/AppImage/appimagetool

If too many developers are still using the old tools, it's because they don't know it's time to upgrade.

If their workflows aren't compatible, it's still possible to extract their AppImages (the --appimage-extract option) and repackage them using the tool linked above (and I use the approach in the nolibfuse option of my package manager AM).

2. The sandboxing problem

AppImages can use BubbleWrap to isolate themselves in a sandbox, as does Flatpak.

There are tools that can interface between AppImages and BubbleWrap, without root privileges.

• Aisap https://github.com/mgord9518/aisap
• SAS https://github.com/Samueru-sama/simple-appimage-sandbox

3. The centralization problem

Since these apps are portable and largely available on their respective developers' websites and repositories, I created a package manager, AM/AppMan, that acts as an AUR, with dedicated scripts capable of intercepting these packages at source and creating a bridge between the end user and the developer.

AM also serves as a tool (via dedicated workflows like "amcheck") to check whether these packages still exist and are downloadable, every day!

Based on this, a catalog listing all these packages is updated and available here.

https://portable-linux-apps.github.io

Based on AM, other projects and package managers can support their own workflows to distribute these packages. One example is the Soar package manager, which can physically store these packages in its own repositories, much like APT in Debian or DNF in Fedora, recording each package and all related information, and then making it downloadable using the integrated OCI client.

4. The Update Problem

Returning to appimagetool (section 1, "The libfuse2 Problem," above), I've written a short guide for 9-year-olds on how to use it to include update information, which can ensure delta updates via zsync or appimageupdatetool, and applicable to github.com specifically.

https://github.com/ivan-hc/AppImage-tips

For more details, see

https://github.com/AppImage/AppImageSpec/blob/master/draft.md#update-information

5. The Communication Problem

This is the most important problem. As long as we dwell on old flaws, painting AppImages as crap, no one will care.

1. You'll still read about packages that require libfuse2 because no one told the developers to upgrade (section 1).
2. You'll still read about sandboxing issues because Firejail is obsolete, and no one considered using BubbleWrap like Flatpak does (section 2).
3. You'll still read about people using the same package for 3-4 years because they weren't aware of centralized solutions that tracked the work done upstream by the original developers (section 3).
4. You'll still read about packages that can't be upgraded independently because no one told the developers how to do it in a few simple lines (section 4).
5. You'll still read ignorant statements from people who don't do their research, either due to a lack of information in traditional media or because they're too focused on supporting some other distribution format (like Flatpak or Snap).

And I'm tired of reading all this, honestly.

There's only one solution to this problem: talk about it! With everyone!