By popular request, I'm asking how do AppImages, which are read-only and stay compressed, store their settings.


From the AppImageKit README:

Special directories

Normally the application contained inside an AppImage will store its configuration files wherever it normally stores them (most frequently somewhere inside $HOME). If you invoke an AppImage built with a recent version of AppImageKit and have one of these special directories in place, then the configuration files will be stored alongside the AppImage. This can be useful for portable use cases, e.g., carrying an AppImage on a USB stick, along with its data.

  • If there is a directory with the same name as the AppImage plus .home, then $HOME will automatically be set to it before executing the payload application
  • If there is a directory with the same name as the AppImage plus .config, then $XDG_CONFIG_HOME will automatically be set to it before executing the payload application

@muru's answer of course is correct and should be upvoted and accepted.

Let me add a few points for clarity:

  • You can make the AppImage create the two directories all by itself by invoking it with the --appimage-portable-home and --appimage-portable-config parameters. This has to be done only once:

    ../some/path/to/my.AppImage --appimage-portable-home
    ../some/path/to/my.AppImage --appimage-portable-config

    This will create the respective (initially empty) directories:

    1. The AppImage will then think that ../some/path/to/my.AppImage.home/ is $HOME.
    2. The AppImage will also think that ../some/path/to/my.AppImage.config/ is $XDG_CONFIG_HOME.

      (BTW, $XDG_CONFIG_HOME very frequently defaults to $HOME/.config.)

  • If you find above two parameters too difficult to remember, then memorize another one: --appimage-help. Using that will list and explain all the others which are available.

  • Not every application makes use of $HOME or $XDG_CONFIG_HOME. In this case your newly created directories will remain empty. Otherwise they'll be populated by the AppImage's payload at runtime and when exiting to all settings it wants to remember.

  • Many applications make use of only one of the two environment variables, $HOME or $XDG_CONFIG_HOME (and therefore of my.AppImage.home/ resp. my.AppImage.config/), not both.

  • Some applications may even get confused if both of the portable settings directories exist...

  • If you re-name the old.AppImage to new.AppImage, the old.AppImage.home/ and old.AppImage.config/ directories immediately cease to work. You need to rename the two directories accordingly: new.AppImage.home/ and new.AppImage.config/.

  • If you rename awesome.AppImage to simply awesome, you have to rename the awesome.AppImage.home/ directory too: namely, to awesome.home/.

  • If you move the AppImage to a new location and want to keep the previously used config and home directories, you have to move these too.

  • If you want to get rid of the old configuration and want to make the AppImage again use "standard" paths for $HOME for $XDG_CONFIG_HOME then simply delete these directories again.

  • If you want a new AppImage's payload to use the same settings as your system-installed version of the payload app, then you should:

    1. Create the relevant empty directory first;
    2. Locate the respective config directory of the system-installed app;
    3. Copy all content of that directory to the new empty one.
  • I wondered if they were being literal about using the "same name as the AppImage". Thanks for confirming. Do you know if AppImages have any support for XDG_CACHE_HOME? – muru Mar 1 '18 at 1:49
  • 1
    When the AppImage startsup, it knows about its current name and absolute path. It then looks if the two named directories exist and have any interesting content for it to read. -- I don't think XDG_CACHE_HOME is currently supported. If XDG_CACHE_HOME isn't present the payload app is supposed to use HOME/.cache... Do you see a use case for where you want to make an AppImage use its own XDG_CACHE_HOME ? In this case, you should maybe submit an issue on their GitHub tracker... – Kurt Pfeifle Mar 1 '18 at 1:56
  • Nah, just wondering why there was support for XDG_CONFIG_HOME without the other XDG directories (cache, data). – muru Mar 1 '18 at 2:15

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.