# ValveSoftware/Proton: building Steam Play's Windows compatibility layer from source

> Proton lets Windows-only games run on Linux through Wine plus DXVK, vkd3d-proton and a set of bundled libraries. Valve ships a prebuilt copy inside the Steam client, so the repository is for people who need to change something in it.

**ValveSoftware/Proton** — GitHub describes it as Compatibility tool for Steam Play based on Wine and additional components. The repository metadata lists C++ as its primary language. The metadata lists the NOASSERTION license. This article stays within the project description and details documented in the GitHub repository README.

- Repository: https://github.com/ValveSoftware/Proton
- Stars: 32,859 · Forks: 1,622
- Language: C++
- License: NOASSERTION
- Published: 2026-08-13 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/valvesoftware-proton

## What Proton actually is, and who the repository build is for

Proton is a compatibility tool used with the Steam client so that games exclusive to Windows run on Linux. The README states it uses Wine to do this, and the top-level tree shows what sits around Wine: dxvk and vkd3d-proton for graphics translation, gstreamer, ffmpeg and dav1d for media, lsteamclient and steam_helper for Steam integration, vrclient_x64 and wineopenxr for VR, plus FEX for ARM64. Those directories are submodules, not vendored copies.

The README is direct about the intended audience: most users should use the Proton provided by the Steam client itself, and the source is published so advanced users can alter Proton, for example to run a different version of Wine with a particular title. That is the whole justification for this repository. If you are not changing something, a source build gives you nothing the client does not already hand you.

## How a Proton build is assembled from submodules

Proton is not one program. It is a build system that compiles Wine and a set of sibling projects, then packages the result as a compatibility tool Steam can select. The repository layout makes the split visible: wine, dxvk, vkd3d-proton, FEX, gstreamer, ffmpeg, OpenXR-SDK, Vulkan-Headers, SPIRV-Headers, glslang, graphene, libsoup, openfst, vosk-api and others each live in their own directory, pulled in through .gitmodules.

Most of the compilation happens inside a container image rather than on the host. The README says most of Proton builds inside the Proton SDK container with very few host-side dependencies, and that the build system uses Docker or Podman internally, so you should never need to invoke either engine by hand unless you are working on the build system itself. The README recommends a rootless Podman setup and points at distribution documentation for both Podman and Docker.

Because subprojects are built in parallel, a single failure can be buried. The README describes the symptom precisely: thousands of lines from other sub-builds can print before the top level exits, so the real cause is hard to find. Its suggested remedy is to log everything and search from the bottom up for the error marker.

```bash
make 2>&1 | tee build.log
grep -n '] Error [0-9]' build.log
```

The README shows what that output looks like, with lines pointing at a .kaldi-i386-configure target and at the deploy target. The point is that the last error in the log is often not the one that broke the build.

## Installing a source build with make install

The repository README gives two paths. The easy path is the top-level Makefile. Clone with submodules, confirm you have a working Docker or Podman setup, then build and install in one step.

```bash
git clone --recurse-submodules https://github.com/ValveSoftware/Proton.git proton
cd proton
make install
```

The README says that if your build system is missing dependencies it will fail quickly with a clear error message. After the build finishes you may need to restart the Steam client for the new tool to appear. Its name in Steam is derived from the currently checked out branch, and you can override that with the build_name variable. Since the default branch here is proton_11.0, an unmodified clone produces a tool named after that branch.

Switching branches means updating submodules, and the README shows the pattern with an experimental branch as the example:

```bash
git checkout experimental_6.3
git submodule update --init --recursive
```

If you want a build you can drop into Steam yourself rather than one installed for you, the README lists make redist, which produces a redist/ directory that can be copied to ~/.steam/root/compatibilitytools.d/. The README also documents make deploy, described as the deployment build Valve uses to ship Proton to Steam users through Steamworks. That distinction matters: redist is for your machine, deploy is the packaging Valve ships. make help lists the other targets.

For manual configuration there is configure.sh, which the README says must be run from a directory created specifically for the build:

```bash
mkdir ../build && cd ../build
../proton/configure.sh --enable-ccache --build-name=my_build
```

The script checks whether containers work and prompts if host-side dependencies are missing. It tries to find a working Docker or Podman setup on its own, and --container-engine lets you force a specific executable. --proton-sdk-image=registry.gitlab.steamos.cloud/proton/soldier/sdk:<version> selects a custom SDK image. The README notes a discrepancy worth flagging: it documents --enable-cache for ccache in one place while the example above uses --enable-ccache, and the top-level Makefile passes --enable-ccache to configure.sh. If the flag is rejected, check --help rather than assuming the build is broken.

## Debug builds, ARM64, and the SELinux trap

Two build variations are documented and both carry conditions. For an unstripped build, add UNSTRIPPED_BUILD=1 to the make invocation, and the README says this should be used only with a clean build directory. The Makefile confirms the coupling: an unstripped variable sets UNSTRIPPED_BUILD=1 and appends _unstripped to the deploy directory name.

```bash
mkdir ../debug-proton-build && cd ../debug-proton-build
../proton/configure.sh --enable-ccache --build-name=debug_build
make UNSTRIPPED_BUILD=1 install
```

ARM64 is the other variation, and it has a hard boundary. You need an ARM64 build machine and must pass --target-arch=arm64 to configure.sh. The README states it is not possible to use the resulting builds in x86 Steam running through FEX. So an ARM64 Proton build is for an ARM64 host, not a way to accelerate x86 titles through FEX on an x86 machine.

The SELinux case is the one most likely to waste an afternoon. If SELinux is in use, the build container may fail to access your user's files because of filesystem labels. The documented workaround is passing --relabel-volumes to configure so the container engine relabels its bind mounts. The README calls this dangerous when used with system directories and says to proceed with caution and consult your container engine's manual. That is not boilerplate caution; relabeling is a property of the path, and pointing it at the wrong directory changes labels outside your build tree.

On iteration speed, the README offers make module=<module> module to build both 32- and 64-bit versions of one wine module, which it says is only useful after building Proton. There are also make dxvk and make vkd3d-proton targets for rebuilding those two components alone.

## Where a source build is the wrong tool

The clearest limitation is stated by the project itself: most users should use the Proton provided by the Steam client. Building from source does not give you a better Proton. It gives you a Proton you can change, at the cost of a container-based build that pulls in Wine and a long list of submodules.

The second limitation is scope. This repository builds a compatibility tool; it does not decide which tool a game uses. Selecting a Proton version, or forcing one per title, happens in the Steam client, and the README only says a restart may be needed for a new tool to appear. Nothing in the documented build flow changes per-game settings for you.

The third is the ARM64 constraint above: if your goal is running x86 Windows games under FEX on an x86 host, an ARM64 Proton build is explicitly not usable for that.

A fourth is that the README does not document rollback. There is no described procedure for reverting an installed local build or for removing one from compatibilitytools.d. The install target writes into your user's Steam directory, so the practical recovery path is deleting the tool directory you created, not a documented command.

Finally, this is not a sandbox. Proton runs Windows game binaries, and the build you produce is a compatibility layer, not a security boundary. Nothing in the README claims otherwise, and no isolation mechanism is described.

## Proton against plain Wine, and what the extra components buy

The obvious alternative is Wine on its own. The difference is not a fork versus upstream; it is a distribution. Proton is Wine plus additional components, and the repository makes that literal: the wine directory sits beside dxvk, vkd3d-proton, FEX, gstreamer, ffmpeg, lsteamclient, steam_helper, vrclient_x64 and wineopenxr.

Running Wine directly means you assemble that stack yourself. You pick a Wine build, install DXVK or vkd3d-proton into the prefix, and handle Steam integration separately, because lsteamclient and steam_helper exist to bridge the game's Steam API calls to the Linux Steam client. Proton's Makefile and configure.sh exist to produce that assembled result as a single tool Steam can launch.

The trade-off runs the other way too. Plain Wine is not tied to Steam, so it works for non-Steam Windows software and for prefixes you configure by hand. Proton's build system is oriented around producing a Steam compatibility tool, with targets like deploy described as what Valve uses to ship to Steam users. If your target is a standalone Windows application outside Steam, the assembled stack here is more machinery than the task needs.

A second comparison point is the Steam client's own Proton versions. Those are the deployed builds. A local build is what you get when you need to change a subcomponent, and the README's own example is using a different version of Wine with a particular title.

## Maintenance, licensing, and what you are signing up for

The repository is not archived, and the last push was on 2026-08-21, which is under a month before today. The most recent release listed is proton-11.0-2 on the same date, following proton-11.0-1b and proton-10.0-4b on 2026-07-28. The default branch is proton_11.0, so branch names track release lines and a build's identity follows the branch unless you override build_name.

That cadence has a direct cost for anyone maintaining a custom build: rebasing your changes onto a new branch means re-checking-out and running git submodule update --init --recursive, then rebuilding the whole stack in the container. The README's note that submodules must be updated when switching between branches is the practical form of that cost. If your modification lives in wine/, you are carrying a patch against a tree that moves.

Licensing needs care rather than confidence here. GitHub reports the license as NOASSERTION, and the repository root contains LICENSE, LICENSE.proton and dist.LICENSE, with the submodule directories carrying their own terms. Wine, DXVK, vkd3d-proton, FFmpeg and the others are separate projects with separate licenses, and dist.LICENSE exists to record what the distributed build contains. If you plan to redistribute a build, read those files and the per-submodule licenses rather than assuming a single license covers the output. This is a description of what is in the tree, not legal advice.

On upgrades: the README documents no versioned upgrade path for a locally installed tool. The documented flow is to build and install, and the tool name follows the branch, so a new branch produces a new tool alongside the old one rather than replacing it.

## Conclusion

Adopt the repository build only if you need to modify Wine itself, swap in a different Wine tree, or produce a redistributable tool for ~/.steam/root/compatibilitytools.d/. If you just want your library to work, use the Proton versions the Steam client already provides, because those are the builds Valve deploys through Steamworks and tests against titles. If you do build, verify three things before trusting the result: that your container engine is rootless Podman or a working Docker setup, that the branch you checked out is the one you meant (the tool name in Steam comes from the branch unless you set build_name), and that the submodules were updated after any branch switch. On SELinux systems, confirm whether you need --relabel-volumes before the first configure, since the README warns that switch can be dangerous with system directories.

## FAQ

### How do I use Proton on Linux?

For normal play you do not build anything: the README says most users should use the Proton provided by the Steam client itself, which ships with several versions selectable in Steam Settings' Steam Play page. The source repository exists so advanced users can alter Proton, for example to use a different version of Wine with a particular title.

### How do I install Proton GE?

The repository does not document Proton GE. It documents building Proton from this source tree with make install, or producing a redist/ build with make redist that can be copied to ~/.steam/root/compatibilitytools.d/. For anything named Proton GE, this README is silent.

### How do I install Proton GE on a Steam Deck?

The README does not cover Proton GE or Steam Deck installation. What it documents is building Proton from this repository and installing it into your user's Steam directory, with make redist producing a redist/ build that can be copied to ~/.steam/root/compatibilitytools.d/.

### What is a Proton?

In this repository, Proton is a compatibility tool used with the Steam client that lets Windows-exclusive games run on Linux, and it uses Wine to do so. It is not the same subject as the other things that share the name in search results.

### How do I use Proton?

Through Steam: the README says most users should use the Proton provided by the Steam client itself, with versions selectable in Steam Settings' Steam Play page. Building from source is described as being for advanced users who want to alter Proton.

## Sources

- [Official README](https://github.com/ValveSoftware/Proton#readme)
- [Project repository](https://github.com/ValveSoftware/Proton)
- [Release notes](https://github.com/ValveSoftware/Proton/releases)

---

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