AppImageKit: What the Repository Still Contains, and What Moved Elsewhere

The problem AppImageKit names, and who it is written for

The README states the format's purpose plainly: packaging applications so they run on a variety of target systems, base operating systems and distributions, without further modification. The list of targets is long and deliberately mixed: RHEL, CentOS, openSUSE, SLED, Ubuntu, Fedora, Debian and derivatives. That is a packaging problem, not an application problem. A developer who builds one binary against one glibc and one set of shared libraries has to rebuild and retest for every distribution they want to reach.

The audience is therefore split. Application developers who want to hand users a single file are the primary audience. End users are the second: the README promises one app equals one file, no unpacking or installation, no root, and no system libraries changed. A third group is less obvious. Because an AppImage can double as a self-extracting compressed archive through --appimage-extract, it also serves people who need to inspect or transport a bundled filesystem image on a machine where FUSE is missing.

What this repository is not is just as important. The README says appimagetool is a low-level tool used to convert a valid AppDir into an AppImage, that it is not needed by end users, and that it is normally not used directly by developers either. It then points to a separate repository. The same pattern repeats for the runtime and for the AppImageSpec. The top-level entries here are only .gitignore, LICENSE, README.md and motivation.md. Anyone arriving from a search for a download should read that as a signpost, not a toolbox.

How an AppImage runs: mount, offset and the payload

The mechanism is described in one sentence: running an AppImage mounts the filesystem image and transparently runs the contained application. Everything else in the README follows from that. The file is an executable with an embedded filesystem image inside it, and a small runtime is part of every AppImage. The README states that the runtime mounts the AppImage and executes the application contained in it, and that the runtime lives in its own repository.

The offset argument exists because the embedded image does not start at byte zero. --appimage-offset prints the offset at which the embedded filesystem image starts and then exits, and the README says this is useful if you want to loop-mount the image with mount -o loop,offset=... . That is the clearest evidence of the layout: a prefix that makes the file executable, then the image.

Two consequences follow. First, the runtime is duplicated inside every AppImage, so the same small piece of code is shipped over and over rather than shared. Second, behaviour depends on the host having FUSE, since mounting is how the payload is reached. The README acknowledges the gap by offering --appimage-extract, which extracts the contents from the embedded filesystem image and exits, described as useful on a system where FUSE is not available. That is a fallback, not an equivalent experience: extraction writes files to disk, and the single-file property is gone for that run.

Portable configuration with .home and .config directories

Most applications write configuration somewhere under $HOME. The README describes a convention that redirects that behaviour when a directory with a matching name sits next to the AppImage. If a directory named after the AppImage plus .home exists, $HOME is set to it before the payload runs. If one named after the AppImage plus .config exists, $XDG_CONFIG_HOME is set to it instead. The README frames this as useful for portable use, such as carrying an AppImage on a USB stick together with its data.

The example uses Leafpad. The reader downloads the AppImage, makes it executable, creates a directory whose name is the AppImage filename plus .config, runs the editor, changes a setting, closes it, and then finds the written file. The output shown is a path under that directory ending in leafpad/leafpadrc. The point is not Leafpad; it is that the redirect is driven purely by directory naming, with no configuration file and no flag.

That is elegant and also fragile. Rename the AppImage and the directory no longer matches. Copy the pair to a filesystem that does not preserve the exact name and the portability silently stops working, with the application falling back to the real $HOME. Nothing in the README describes a warning when the expected directory is absent, so a user cannot tell from the outside whether the redirect took effect.

Installing AppImageKit tooling and a first real use

The README does not give install steps for AppImageKit itself. It states that appimagetool is not needed by end users and normally not used directly by developers, and it directs readers to the repositories for appimagetool, the type 2 runtime and the AppImageSpec. So the honest starting point is: get the tool from the repository the README names, not from this one.

What the README does document is how to use an AppImage you already have. The first step is making the file executable, which the README links to a forum post titled how to make an AppImage executable. The Leafpad example shows the command:

chmod a+x Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage

After that, running the file executes the contained application. To confirm which runtime you are dealing with before filing a bug, the README provides a version flag:

./Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage --appimage-version

It prints the version of AppImageKit and exits. If the AppImage was built with older tooling, the README warns that these options may be unsupported and suggests asking the author to rebuild with the latest tooling.

For portable settings, create a directory named after the file plus .config, then run the AppImage and change a preference:

mkdir Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage.config
./Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage
find Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage.config

The find output should show the application's configuration file written inside that directory, which is how you confirm the redirect happened. On a machine without FUSE, the alternative is extraction:

./Leafpad-0.8.18.1.glibc2.4-x86_64.AppImage --appimage-extract

This writes the contents out and exits instead of mounting them.

Where AppImageKit is the wrong choice

The format's strengths are also its limits. The README says no system libraries are changed and no root is needed. The trade-off is that the application cannot rely on the host to patch a bundled library. If a library inside the image has a security flaw, the fix arrives only when a new AppImage is built and the user replaces the file. Distribution package managers handle that for their own packages; an AppImage sits outside that pipeline.

FUSE is the second boundary. Mounting is the normal path, and the README offers extraction only as a workaround for systems where FUSE is unavailable. Extraction is a different mode of operation, not a transparent substitute, so environments that block FUSE by policy are a poor fit unless you accept the extracted workflow.

Staleness is visible in the repository itself. The releases listed are marked obsolete: continuous from 2023-03-08, 13 from 2020-12-31, and 12 from 2019-05-01. The last push to the repository was on 2026-07-26, which is recent, but the README's own direction of travel is away from this repository and toward the runtime, spec and appimagetool projects. A team that wants the current tooling should not anchor its build process here. And if the requirement is a managed, centrally updated application with shared dependencies and desktop integration handled by the system, the AppImage model is the wrong shape; it is built for self-contained files that the user carries.

AppImage compared with Flatpak, and with plain distribution packages

Flatpak is the comparison users ask about most, and the difference in approach is structural. AppImage is one file that the user downloads, marks executable and runs; the README says no unpacking or installation is necessary, no root is needed, and no system libraries are changed. Flatpak is a system-installed runtime with applications layered on top, which means a shared runtime that can be updated independently of the applications using it. That shared runtime is exactly what an AppImage does not have, because the runtime and the libraries travel inside each file.

The practical split follows. Flatpak suits a machine where an administrator installs and updates software centrally, and where sandboxing and shared dependency updates matter more than portability. AppImage suits handing a single file to someone who may be on any of the distributions the README lists, who cannot or should not install packages, and who may be running from a Live ISO. The README explicitly notes that AppImages work on Live ISOs and can be used across dual-boot setups, which is a case Flatpak does not serve in the same way.

Against ordinary distribution packages, the difference is reach. A .deb or .rpm is built for a family of distributions and depends on what that distribution provides. The README's framing is the opposite: the same file runs across RHEL, CentOS, openSUSE, SLED, Ubuntu, Fedora and Debian. You trade integration and central updates for that reach.

Maintenance, licensing and what to check before adopting

The repository is not archived, and its last push was on 2026-07-26. That tells you the repository is still touched, but it does not tell you the format tooling is developed here; the README redirects appimagetool, the runtime and the spec to their own repositories, and the releases listed here carry the obsolete label. Treat this repository as documentation of the format's behaviour and history rather than as the place to track current development.

The licence field on the repository is NOASSERTION, which means the hosting platform could not map the LICENSE file to a recognised identifier. The README carries a copyright line for Simon Peter and contributors covering 2004 to 2024. If you plan to redistribute AppImages or embed the runtime in a commercial product, read the LICENSE file in the repository root and the licences of the runtime and tooling repositories separately, since they are distinct projects. That is a reading task, not a legal conclusion, and the README does not spell out the terms.

Upgrade cost has two layers. For the tooling, upgrading means moving to the repositories the README names, which is a change of source rather than a version bump. For users, upgrading an AppImage means replacing a file. The README mentions optional binary delta updates for continuous builds using AppImageUpdate, and optional GPG2 signing inside the file, with --appimage-updateinformation and --appimage-signature to inspect what is embedded and a separate validate tool to check the signature. Those features depend on the AppImage having been built with the update information and signature in place, which is a property of the file you receive, not of this repository.

Editorial conclusion

Adopt AppImageKit's format if you ship a desktop application to many Linux distributions and want one file that runs without root and without touching system libraries. Do not treat this repository as the source of appimagetool or the runtime; the README redirects both to their own repositories, and the newest release listed here is marked obsolete. Before committing, verify that the AppImage you build actually starts on the oldest distribution you support, and check whether FUSE is present on the machines your users run, since the README offers --appimage-extract as the fallback when it is not.

Frequently asked questions

Official sources

1. AppImage/AppImageKit on GitHub
2. Issues
3. Project website
4. README
5. Releases