# protonup turns Proton-GE installation into a version-pinned command

> protonup is a small Python CLI, with an API alongside it, that installs and updates Proton-GE builds into a Steam compatibilitytools.d directory. It handles listing available versions, pinning a specific release, downloading without installing, and removing installations that you no longer want.

**AUNaseef/protonup** — Install and Update Proton-GE

- Repository: https://github.com/AUNaseef/protonup
- Stars: 601 · Forks: 23
- Language: Python
- License: GPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/aunaseef-protonup

## The manual Proton-GE dance this script removes

Proton-GE is the custom Proton build maintained by GloriousEggroll, published from the proton-ge-custom repository, and it is what many Linux players use to run Windows games through Steam. The README describes protonup as a CLI program and API to automate the installation and update of that project.

The work it removes is unglamorous and easy to get wrong. You need a build, you need it placed where Steam looks for third-party compatibility tools, and you need a way to know which build is sitting there and whether a newer one exists. Done manually that means finding a release tag, downloading an archive, unpacking it into the right directory and repeating the whole thing when an update lands.

The audience is narrow and obvious. It is the Linux user whose Steam library lives under a compatibilitytools.d directory, who plays a title that needs a specific Proton version, and who would rather type one command than repeat an archive extraction after every Proton-GE release. The API side of the project points the same way: the tool is meant to be called from a script that provisions machines, not only from a shell.

Everything the tool does is scoped to Proton-GE. It is not a general Steam manager and does not touch your library, your games or your Steam settings.

## Every flag maps to one decision about a build

The command surface is small and each option answers a single question.

The directory flag, given as -d with a path, names the installation directory, described as the compatibilitytools.d directory of your Steam installation. The README is explicit that you set this before running the program, and the example uses the standard Steam root path.

The version tag flag, -t, installs one specific version rather than the newest, with the example given as 6.5-GE-2. That form is the naming scheme Proton-GE releases use, and the flag is the reason the tool is useful in a script: you can pin the exact build a game needs and reproduce it later.

The output flag, -o, changes where downloads are stored. By default the downloads go to a temporary folder, so this flag matters when you want the archive to survive for inspection or for a manual install elsewhere.

The listing flag, -l, lists existing installations, and the removal flag, -r with a version tag, removes an existing installation. The releases flag, --releases, lists available versions instead of acting on them.

Two flags control the shape of a run rather than its target. The --download flag fetches Proton-GE into the current working directory without installing it, and the destination can still be overridden with -o. The -y flag carries out actions without any logging or interaction, which is what makes the tool usable from an unattended script.

## Installing protonup and pointing it at Steam

The documented installation path is the Python Package Index:

```bash
pip3 install protonup
```

The alternative is to install from source, which the README gives as a clone followed by a local install:

```bash
git clone https://github.com/AUNaseef/protonup && cd protonup
python3 setup.py install --user
```

That second route installs into your user site, which is where the next step comes from. The README warns that you may hit a command not found error, and the fix is to make sure the user binary directory is on your path:

```bash
if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi
```

Add those lines to your ~/.profile if they are not already there, then run source ~/.profile so the current shell picks them up. The check for the directory existing is there so the snippet is harmless on a machine where that path does not apply.

Once the command resolves, the first real action is to tell the tool where Steam keeps its compatibility tools, using the directory flag:

```bash
protonup -d "~/.steam/root/compatibilitytools.d/"
```

That installs Proton-GE into the location Steam scans. Running protonup with no further flags afterwards updates to the latest version, which the README describes as the whole of the update procedure.

## Listing what is installed and removing what is not

Before changing anything, the two listing modes answer two different questions. One asks what exists locally:

```bash
protonup -l
```

The other asks what can be installed:

```bash
protonup --releases
```

Those answers are worth keeping separate in your head. The list of available releases tells you what tags exist upstream and what a version tag argument like 6.5-GE-2 looks like in practice. The list of existing installations tells you what is already unpacked in the directory you passed with -d. Neither is a substitute for the other, and mixing them up is how you end up trying to install a build that is already there.

Removing is by explicit version tag, so nothing is deleted by accident:

```bash
protonup -r 6.5-GE-2
```

If you want the archive without the installation, --download fetches Proton-GE into the current working directory, and -o redirects that destination. Combining that with -y gives you a quiet, non-interactive fetch:

```bash
protonup --download -o ~/Downloads -y
```

The -y flag is documented as toggling actions without any logging or interaction, so this form is the one to script. For the ordinary interactive case, leaving it off keeps the tool's prompts visible, which is the safer default when you are moving a build that a running game depends on.

## The README ends with an empty section about restarting Steam

The last heading in the README is Restart Steam after making changes, and nothing follows it. That is not a formatting quirk to ignore, it is the main operational gap in the documentation. Any change protonup makes to the compatibilitytools.d directory is only picked up by Steam when the client is restarted, and the project says so without saying how, when, or whether a full quit is required rather than a window close.

Two other gaps are worth naming. The usage text is framed around a compatibilitytools.d path of the kind shown in the example, and the topic tags for the repository include Linux, Steam and Python, so nothing in the documentation suggests support for a platform where Proton-GE is not used in the same way. And there is no documented behaviour for what happens when the target directory does not exist, or for the temporary folder used by default when a download is interrupted.

A third factor sits outside the README. The published releases are 0.1.5 from 2023-01-12, 0.1.4 from 2021-08-19 and 0.1.3 from 2021-05-03, while the last push was on 2026-08-31. Commits continue to land on the main branch, but the version a pip install gives you has not moved since January 2023. That gap matters more here than in a typical project, because the tool's job is to track releases that ship far more often than protonup does.

## Extracting the archive yourself instead of running protonup

The honest alternative is manual installation, and for a single build it is entirely reasonable. You locate the Proton-GE release you want from the GloriousEggroll repository, download its archive, unpack it into the Steam compatibilitytools.d directory yourself, and restart Steam. Nothing about that requires a script, and it avoids adding a Python tool to a machine that only needs the job done once.

The difference in approach comes down to repeatability. Manual extraction gives you one build at a time, and keeping track of what you have installed means remembering what you unpacked. protonup keeps the same directory as its working area but adds a listing mode, so you can ask what is installed instead of recalling it. It also adds update as a single command, since running protonup with no flags updates to the latest version.

The pinned case is where the manual route gets awkward. If game A needs build 6.5-GE-2 and game B needs a newer one, a user juggling both ends up with several unpacked directories and no tool to enumerate them. The version tag flag plus the removal flag let the same person hold two builds, see both in the list, and drop the one they no longer need.

One more difference is the interface. protonup ships as a CLI program and an API, so the same operations can be driven from a provisioning script, while manual extraction is a step a human performs.

## Licence, packaging and what a version tag commits you to

The repository is licensed under GPL-3.0, which for most users of this tool means something simple: you may use it, study it, modify it and redistribute it, and if you distribute a modified version you carry the same licence and pass on the source. The practical trigger for most people is not redistribution but modification, since the typical use here is running it as installed from the Python Package Index.

Packaging is minimal and unremarkable. The build backend is setuptools with wheel declared in pyproject.toml, setup.py is a two-line script that calls setuptools.setup(), and the configuration lives in setup.cfg with the package code under a protonup/ directory. There is also a .gitignore and a LICENSE file at the root. Nothing in the layout suggests a heavy dependency tree, which matches the project's stated job.

The tag format is the part people get wrong. A version argument such as 6.5-GE-2 is the release identifier used by Proton-GE itself, and the -t flag expects that exact string. Guessing a number that looks close will simply not match a release, so the --releases listing is the reliable way to learn the current set of tags before you pin one.

For a script, the combination that matters is a fixed -d directory, a fixed -t tag, and -y for silence, which together make an installation reproducible across machines as long as the upstream tag still exists.

## Conclusion

protonup is worth adopting if you switch between Proton-GE builds often, if you script Steam setup on several machines, or if you want a recorded list of what is installed and the ability to remove a build without hunting through directories by hand. Skip it if you install one build and never touch it again, if your platform is not Linux, or if your team needs an actively published release, since the newest tagged release is 0.1.5 from 2023-01-12 even though the last push was on 2026-08-31. Before you rely on it, run protonup --releases to confirm the version tags it offers are current, then list what is already installed with protonup -l so you know what a removal with -r would affect.

## FAQ

### How do I install protonup and install Proton-GE into my Steam directory?

Install it with pip3 install protonup, then point it at the Steam compatibility tools directory using protonup -d with that path, for example protonup -d "~/.steam/root/compatibilitytools.d/". If a source install leaves you with a command not found error, add the user bin directory to your path as the README describes.

### How do I update Proton-GE with protonup?

Run protonup from a command line with no other arguments, which the README describes as updating to the latest version. To pin a specific build instead, pass its tag with -t, for example protonup -t 6.5-GE-2.

### How can I list and remove Proton-GE installations with protonup?

Use protonup -l to list existing installations and protonup --releases to list the versions available upstream. Removing takes the version tag, so protonup -r 6.5-GE-2 deletes that specific installation.

### Does protonup need Steam to be closed before it changes anything?

The README closes with a section titled Restart Steam after making changes, and the section has no further text, so the requirement is stated without instructions. There is no documented alternative path that avoids restarting the client.

## Sources

- [AUNaseef/protonup on GitHub](https://github.com/AUNaseef/protonup)
- [Issues](https://github.com/AUNaseef/protonup/issues)
- [License: GPL-3.0](https://github.com/AUNaseef/protonup/blob/main/LICENSE)
- [README](https://github.com/AUNaseef/protonup/blob/main/README.md)
- [Releases](https://github.com/AUNaseef/protonup/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aunaseef-protonup