This should be installed as default in all distro. Run it with --install, put appimages in ~/Applications and it’s done, you’ll see all apps in your DE app menu
This is neat but honestly im looking for something more akin to portable apps where it is a seperate gui that you put anywhere and it keeps its own sub file structure and does not integrate with the os. you set it to auto start or such if you want.
Overall there should be repo for appimages which just don’t have flatpak, for some apps which can’t work well in sandbox.
appman pretty much does this.
the people behind the appimage spec at https://appimage.org/
… have a listing of available software at https://appimage.github.io/
note that this isn’t a curated repository like your os repos, but rather a directory of community-provided submissions that pass some basic automated tests.
Does it have GUI?
https://github.com/Shikakiben/AM-GUI
It was recently tested on postmarketOS here btw
I agree, this is a very handy app, and I felt very similarly when I first discovered it. That said, I’ve had some issues with AppImageInstaller that I haven’t had with GearLever, it’s nearest equivalent. That’s the beauty of Linux FOSS though, so many choices :)
No appimage for gearlever???
GearLever is my pick too. It does its job, not perfect but good. Updates can be tricky tho sometimes.
Thanks for sharing! This APP looks very interesting for non tech people
The only drawback is that it doesn’t have an app catalogue. For novice users that would be great. Otherwise, GearLever is superior in every aspect.
I’ve had some issues with AppImageInstaller that I haven’t had with GearLever
Would you be so kind to elaborate? Being explicit would already make a huge difference. Thank you in advance!
No one mentioned it yet, but there’s also AppManager.
GearLever works better
Does it manage the --no-sandbox option often needed?
I have never used that flag. Does that just enable full system access without the usual layer of sandbox protection?
Yes,and it’s the only way to start some apps on Ubuntu
Don’t run electron/chromium apps with
--no-sandbox, that is not safe, you are exposing yourself to the internet.Canonical decided on ubuntu 24.04 to disable unpriv namespaces in the name of security, in reality they did it to push snaps since that change breaks appimage and flatpak.
Do what linux mint ended up doing and disable the restriction.
kernel.apparmor_restrict_unprivileged_userns = 0' | sudo tee /etc/sysctl.d/20-fix-namespaces.conf sysctl -w kernel.apparmor_restrict_unprivileged_userns=0Or better yet just don’t use ubuntu, it is just a source nightmares, the uuttils switch even broke one of my appimages…
Okay, well gear lever lets you add command line arguments which get saved in the config so that should work easily. I will say it’s odd to me that you say this is needed for a specific OS, let alone often. I have never used that flag and I’ve been using an Ubuntu variant for ~5 years now. Doesn’t mean you’re wrong or anything, I’m just surprised because that seems to defeat one of the main purposes of appImages. The whole security/safety model seems to be sidestepped if you use that flag. I tend to only use appImage if it’s my only option because flatpaks seem to work better in my experience.
Gearlever doesn’t even do delta updates, it downloads the whole appimage with every update, and you often have to manually give it the URL to update the appimage.
It is also a total hack written in python, the dev was even shelling out
archto find the host arch instead of using the built in methods of python…All I know is appImageLauncher gave me a lot of issues so as soon as I found an alternative I tried it and haven’t had an issue yet.
Edit: apparently having an experience gets a downvote. Pretty whiny and weird thing to do.
All I know is appImageLauncher gave me a lot of issues so as soon as I found an alternative I tried it and haven’t had an issue yet.
You likely ran an outdated version of appimagelauncher.
appimagelauncher for broken for several years when the static appimage runtime came up, the stable release didn’t support it. So it would cause people to not be able to launch appimages at all.
It was fixed in the nightly releases but most people had no idea about that.
But anyways appimagelauncher right now does not support DWARFS as well, so it is not able to integrate other appimages. So do not go back to appimagelauncher.
Edit: apparently having an experience gets a downvote. Pretty whiny and weird thing to do.
Just in case it is not me that downvoted you lol
You likely ran an outdated version of appimagelauncher
I’m just curious how you think this would have happened. Did I install it, not use it for months, never update my system, then start using it?
I am not sure it matters why or what issues I had, but I had a few, enough to look for an alternative. In fact my experience with AIL is part of the reason I avoid appImages. They just don’t seem to work well in my experience. In any case you were dismissive in your first message and really negative about software that works fine for me, citing reasons that don’t seem relevant to my use case, about details that never seemed to impact me. I just know I tried to use AIL for a couple of years and had issues multiple times, the last time resulting in breaking an app. So I stopped using it.
I’m just curious how you think this would have happened.
because unless you went out of your way to build appimage luancher or install the nightly releases you would have run into that problem.
That problem was serious enough that we had to add a warning to all of our appimage repos to give you an idea. lsfg-vk even had it happen several times in 2025 💀
- https://github.com/PancakeTAS/lsfg-vk/discussions/351
- https://github.com/PancakeTAS/lsfg-vk/discussions/336
And note removing/updating appimage launcher wasn’t enough, you also had to reboot, because the thing had a daemon with a binfmt rule that would still prevent you from launching appimages.
In any case you were dismissive in your first message and really negative about software that works fine for me,
I’m very sorry, I thought you were responding to this message about AppManager hence my tone.
AppManager is good.
If you wonder why AppImage had to update the appimage runtime, that is because the static runtime removed the libfuse2 dependency, which was a huge issue appimage had for a long time and to this day I still see people claim this is still a problem. It resulted in that mess with AppImageLauncher unfortunately.
I update my system often and believe it or not reboot more than once every couple years ;) I’m clueless about all these details I just know from a user perspective I had some annoyances and breakages.
I am not familiar with AppManager at all.
I just put appimage files in my $PATH. what else does this do?
I believe it also generates menu entries (.desktop files) for them.
GearLever will also perform automatic updates for your AppImages
(now if AppImages would work on musl systems …)
AppImageLauncher works as intended.
But, if you are willing to use the terminal, then there’s appman. Appman is a terminal package manager for handling appimages, which also integrates appimages into the system. It can update appimages, as well as install images that are not found on its package database.
I just keep all my AppImages on a favorited folder…
I’ve been perfectly happy with AppImageInstaller. It’s an easy way to generate .desktop files and has a provision for manual AppImage updates. It’s worked without any issues for all (only six) of the AppImages I’ve installed. I hadn’t heard of GearLever but now I’ll give a try.
Is it just me that has problems with it? Certain appimages being broken and shit.
Its nice to see developers wearing hijabs.
