| description | If you're using Linux follow this guide! |
|---|---|
| icon | linux |
RiftLauncher works on ANY Linux distro thanks to the AppImage compilation we're using.
Installing it on Linux is as easy as downloading the AppImage and double clicking it.... that's it. Let's get started:
{% hint style="success" %}
If you're using Arch Linux or a derivative there is a .pacman package on the releases page. Community AUR packages are welcome. riftlauncher-bin is one, maintained outside Stratum: we do not build or support it. If you want to package RiftLauncher yourself, say hi on the Stratum Discord server so we can coordinate. There is no distro repository, so your first install comes from the releases page or from a community AUR package.
{% endhint %}
{% hint style="warning" %}
AUR installs and the built-in updater. The built-in updater runs on any .pacman install: it downloads the release .pacman and installs it through pacman, using the package marker electron-builder writes next to the app. On an AUR install that puts the launcher and your package manager in charge of the same files, so update an AUR install through your package manager: yay -Syu or paru -Syu. The maintainer of riftlauncher-bin reports on issue #262 that it updates cleanly that way. If you maintain an AUR package, document the update path in its description.
{% endhint %}
{% stepper %} {% step %} Go to the GitHub Releases Page
On that page you'll see all the available versions to download. {% endstep %}
{% step %} Download the Linux version
On the releases page, the first version is always the latest one. There you'll see a table with the different files to download. The one you want is riftlauncher-X.X.X.AppImage, where X.X.X is the version number.
{% hint style="info" %}
Every release ships four Linux builds: riftlauncher-X.X.X.AppImage, .deb, .x86_64.rpm and .pacman. There is no Flatpak build; the runtimes it needs aren't available on our build machines.
If you prefer a packaged install over the AppImage, install the .deb, .rpm or .pacman once and then skip steps 3, 4 and 5:
sudo dpkg -i riftlauncher-X.X.X.deb
# or
sudo rpm -i riftlauncher-X.X.X.x86_64.rpm
# or
sudo pacman -U riftlauncher-X.X.X.pacmanFrom there just open it like any other app. All three update themselves the same way the AppImage does, except that replacing an installed package needs elevated privileges, so RiftLauncher will show a system password prompt (pkexec, sudo or similar) each time it applies an update.
{% endhint %}
{% endstep %}
{% step %} Move the AppImage to an accesible location
For example the Desktop, the you'll be able to open it whenever you want.
{% hint style="warning" %} Some users reported that AppImage Launcher is breaking automaitc updates so if you want to use it make sure to download the latest RiftLauncher version when it's published! {% endhint %} {% endstep %}
{% step %} Add execution persmissions
This should be done by default by sometimes you've to manually do it.
chmod +x ./riftlauncher-X.X.X.AppImage{% endstep %}
{% step %} Open RiftLauncher
Double click the AppImage and that's it, ready to use! {% endstep %}
{% step %} Install Dependencies
RiftLauncher does not need any dependecy to work but Vintage Story does so follow the next steps. {% endstep %} {% endstepper %}
AppImage installs can keep RiftLauncher's profile beside the AppImage. Close RiftLauncher, open a terminal in the folder containing the AppImage, and create an empty marker file:
touch RiftLauncher.portableOn the next launch, RiftLauncher creates a RiftLauncherData folder beside the AppImage. The first portable launch copies the existing ~/.config/RiftLauncher profile and leaves the original in place. Chromium's regenerable disk caches are skipped, while saved background images under Cache/Backgrounds are copied. New Installations, VS Versions and Backups default under the portable data folder. Existing custom folder paths and game files are not moved.
This marker is supported for AppImages. .deb, .rpm and .pacman installs continue to keep their profile in the usual Linux data folder.
The single-instance lock stays separate from the portable profile, in the normal app data folder as RiftLauncher.singleton.
RiftLauncher does not need any dependencies to work, but Vintage Story does. This process isn't automated on game launch, since Linux has too many distros to personalize it for all of them, so you'll have to do it manually.
To help you with this process we've made a few guide explaining how to install every dependency needed on the most popular Linux distros.
The biggest one is .NET, and it belongs to the game rather than to the launcher: RiftLauncher runs fine without it, Vintage Story does not start at all. Which major version you need depends on the game version you play (7, 8 or 10), so installing several side by side is normal, and a version that used to launch can stop launching once you move to a newer game build.
{% stepper %} {% step %}
wget https://dot.net/v1/dotnet-install.sh -O dotnet-install.shchmod +x ./dotnet-install.shsudo ./dotnet-install.sh --channel 7.0 --install-dir /usr/share/dotnetsudo ./dotnet-install.sh --channel 8.0 --install-dir /usr/share/dotnetsudo ./dotnet-install.sh --channel 10.0 --install-dir /usr/share/dotnet/usr/share/dotnet is the apphost's own compiled-in default, the last place it looks when nothing tells it otherwise, so installing straight there is the simplest option: no registration file to write and nothing that can drift out of sync later.
{% hint style="info" %}
Installing somewhere else. If you'd rather keep the game's .NET out of /usr/share/dotnet, install with --install-dir /usr/lib/dotnet instead and register that location by hand:
echo /usr/lib/dotnet | sudo tee /etc/dotnet/install_location /etc/dotnet/install_location_x64Newer .NET hosts (10 and later) read the architecture-specific file, install_location_x64 here, instead of the plain install_location, so write both: dotnet-install.sh sets neither, and without them the runtimes you just installed stay invisible to Vintage Story. Point the symlink below at /usr/lib/dotnet/dotnet instead of /usr/share/dotnet/dotnet if you go this route.
{% endhint %}
sudo ln -s /usr/share/dotnet/dotnet /usr/bin/dotnetThis just puts dotnet itself on your PATH, which you need for the check below and for any other tool that expects dotnet to exist.
Check it
dotnet --list-runtimesshould list a Microsoft.NETCore.App entry for whichever major version, 7, 8 or 10, the game version you play needs.
{% hint style="warning" %}
If RiftLauncher says a .NET runtime is missing and a copy of the game ran fine before, that older copy most likely shipped its own runtime alongside the game files. The versions RiftLauncher lists as installed come from the system-wide .NET install above, not from a bundled copy, so the two don't tell you the same thing. The exact locations the .NET host searched and didn't find anything are printed in verbose.log if you want to see them, for example:
Environment variable: DOTNET_ROOT_X64 = <not set>
Environment variable: DOTNET_ROOT = <not set>
Registered location: /etc/dotnet/install_location_x64 = <not set>
Default location: /usr/share/dotnet
If your runtime lives somewhere none of those point to, you can set DOTNET_ROOT for a single Installation instead of touching the system-wide registration: put DOTNET_ROOT=/usr/lib/dotnet (or wherever you installed it) in that Installation's ENV variables field in the Advanced section.
{% endhint %}
{% endstep %}
{% step %}
You'll have to look up how to do this for your graphics card and your Linux distribution as the combinations are almost endless! {% endstep %}
{% step %}
sudo apt install libopenal-dev mono-complete{% endstep %}
{% step %}
sudo sysctl -w vm.max_map_count=262144{% endstep %} {% endstepper %}
{% stepper %} {% step %}
You'll have to look up how to do this for your graphics card and your Linux distribution as the combinations are almost endless! {% endstep %}
{% step %}
sudo pacman -S dotnet-runtime-7.0 dotnet-runtime-8.0 dotnet-runtime glibc openal opengl-driver monoUnlike the script-based install above, there's nothing to register by hand here: Arch's dotnet-runtime packages write /etc/dotnet/install_location themselves as part of installation.
{% endstep %} {% endstepper %}
{% stepper %} {% step %}
SteamOS is protected so you can't make changes by accident. To install the dependencies you need to disable this:
sudo steamos-readonly disable{% endstep %}
{% step %}
Sometimes you'll need to do some steps to configure everything:
sudo pacman-key --init
sudo pacman-key --populate archlinux
sudo pacman-key --populate holo{% endstep %}
{% step %}
sudo pacman -S dotnet-runtime-7.0 dotnet-runtime-8.0 dotnet-runtime glibc openal opengl-driver mono{% endstep %}
{% step %}
sudo steamos-readonly enable{% endstep %} {% endstepper %}
{% hint style="info" %} This sequence is inherited from the original VS Launcher docs, where it came from a user who got it working on their own machine. Nobody on the current team has a Steam Deck, so it has never been reproduced or verified step by step. If you run it and something is off, a report on the Stratum Discord server would be very welcome. {% endhint %}
{% stepper %} {% step %}
Appimages require a couple of options to be enabled in order to load, and they cannot see system libraries such as dotnet. Simply add this to your config to enable appimage support, and reveal the missing dotnet library:
programs.appimage.enable = true;
programs.appimage.binfmt = true;
programs.appimage.package = pkgs.appimage-run.override { extraPkgs = pkgs: [
pkgs.dotnet-runtime
]; };{% endstep %} {% endstepper %}
{% hint style="info" %} Note, that this will enable appimages system-wide, and all appimages will have dotnet available to them. {% endhint %}
When you log in, RiftLauncher hands your session to the desktop's own keyring instead of keeping it in a file of its own. On Linux that is GNOME Keyring or KWallet, reached through libsecret. The .deb and .rpm packages already depend on libsecret, and the .deb recommends gnome-keyring for desktops that have no wallet of their own, so most installs need nothing here.
If no keyring answers, Electron falls back to a store that seals the session with a key built into the launcher, which means any program running as you can read it. RiftLauncher refuses that store by default. You can still log in and play: the session is kept in memory for as long as the launcher is open, and you log in again next time. The launcher says so when it happens.
GNOME Keyring is installed and unlocked with your session by default, so there is nothing to do. If you removed it, sudo apt install gnome-keyring or sudo dnf install gnome-keyring puts it back.
KWallet is installed with Plasma but it can be switched off, and a wallet that does not exist is the same as no keyring at all. Open System Settings, go to KDE Wallet, tick Enable the KDE wallet subsystem, and create a wallet if there is none. Blowfish and GPG both work. If you give the wallet a password, you will be asked for it once per session, the first time something reads it.
kwalletmanager is worth installing if you want to look at what is stored: it lists the wallets, shows the entries in them, and can create a wallet without going through System Settings.
Sway, i3, Hyprland and the like start nothing of this sort on their own. Install gnome-keyring and have your session start the daemon, for example by launching your window manager through dbus-run-session -- gnome-keyring-daemon --start --components=secrets or by adding the daemon to whatever your session already starts. What matters is that the daemon is running and unlocked in the same session as the launcher.
There is a setting for it. In Settings, turn on Remember the session without a system keyring, then restart RiftLauncher: Chromium picks its storage as it starts, so the setting only takes effect on the next launch.
Be clear about the trade. With that setting on, your session is written to disk sealed with a key that ships inside the launcher, the same key in every copy of it. Anyone who can read your files, and any program running under your account, can read the session and use it as you. On a machine you alone use, that may well be a fair price for not logging in again every time. On a shared or managed machine it is not. That is why the setting is off until you turn it on.
By default, Linux builds store their config, game-version list and installations in /home/username/.config/RiftLauncher/. An AppImage with the RiftLauncher.portable marker instead keeps its profile beside the AppImage in RiftLauncherData. Debian, RPM and pacman packages continue to use the default location.
If you're coming from VS Launcher, its folder is /home/username/.config/VSLauncher/ and RiftLauncher never writes to it. On first launch, if no RiftLauncher profile exists yet, RiftLauncher copies VS Launcher's config.json and installation icons into its profile. This migration also runs when RiftLauncher uses its default folder. If a RiftLauncher profile already exists, portable setup copies that profile instead. The originals are never modified.
The copy skips Chromium's regenerable caches, including Cache/Cache_Data and Cache/No_Vary_Search, but keeps saved background images in Cache/Backgrounds. It does not move game files or custom folder paths: config.json stores absolute paths, so the portable folder cannot be moved afterwards without editing them. A portable folder carried to another machine keeps its settings and installations but not its saved sessions, because those live in the system keyring of the machine and account where they were saved. Linux also requires the empty marker file and the portable data folder to be owned by the account running RiftLauncher; another account cannot use that profile.
{% hint style="info" %} If you find any issue report it on the GitHub Issue Tracker and if you need help ask us on the Stratum Discord server, the GitHub Discussions or the Official Vintage Story Discord Server. {% endhint %}