WinApps runs a whole Windows VM behind FreeRDP, and the compose defaults are where the work is

Four moving parts: a Windows VM, an app scan, host shortcuts, FreeRDP

The project states its own mechanism in four steps, and reading them tells you what kind of thing this is. It runs Windows in a `Docker`, `Podman` or `libvirt` virtual machine. It queries Windows for all installed applications. It creates shortcuts to selected Windows applications on the host GNU/Linux desktop. And it uses `FreeRDP` as the backend that renders those Windows applications alongside your Linux ones.

The phrase to notice in that list is virtual machine. WinApps is not a translation layer and not an interpreter; it boots an actual copy of Windows and connects to it over Remote Desktop. Every cost that implies is a cost you pay: startup time, memory, disk, and a Windows licence. In exchange you get the real application behaving the way it behaves on Windows, which is the entire reason anyone reaches for something in this category.

It is also a hard fork of `Fmstrat/winapps`, which is worth knowing before you read anything else about where its behaviour came from.

Docker, Podman or libvirt, and where your 64G disk ends up

The backend is a choice, and the choice is not cosmetic. Three are named as ways to run the Windows VM, and the difference surfaces in the filesystem before you install anything at all.

`compose.yaml` creates a volume called `data`, and the comments in that file record where each runtime puts it. Under Docker it is `/var/lib/docker/volumes/winapps_data/_data`. Under Podman it is `/var/lib/containers/storage/volumes/winapps_data/_data` or `~/.local/share/containers/storage/volumes/winapps_data/_data`. Under libvirt you are outside both of those paths entirely, since libvirt is named in the mechanism as a third option that is not one of the container runtimes.

So the decision determines where the Windows disk and everything you install into it lives, and whether your distribution's storage stack is what owns it. The repository root also holds `flake.nix` with `flake.lock` and a separate `default.nix`, alongside `bin/`, `packages/` and `install/`, which is the other way this project is distributed.

compose.yaml is where every decision you want to make is made

Sizing, Windows version and credentials all live in one file. The service is called `windows`, the container is named `WinApps`, and it is built from an image that belongs to a different project:

image: ghcr.io/dockur/windows:latest
container_name: WinApps
VERSION: "11"
RAM_SIZE: "4G"
CPU_CORES: "4"
DISK_SIZE: "64G"

Those numbers are the honest specification of what this costs you. Windows 11, four cores, four gigabytes of RAM and a sixty-four gigabyte primary disk are the out-of-the-box values, and a second disk sits in the file but commented out.

Networking is loopback only, which is the right default:

- "127.0.0.1:8006:8006"
- "127.0.0.1:3389:3389/tcp"
- "127.0.0.1:3389:3389/udp"

Port 8006 is a VNC web interface you open in a browser at `http://127.0.0.1:8006`, and 3389 is Remote Desktop over both TCP and UDP. Because both bind to 127.0.0.1 on the host, nothing outside your machine reaches the VM until you change that yourself.

The shipped Windows account is a placeholder, and the image tag is latest

Two defaults deserve attention before the first boot. The first is the Windows account:

USERNAME: "MyWindowsUser"
PASSWORD: "MyWindowsPassword"
HOME: "${HOME}"

The comments beside those lines state the defaults outright, and they sit in a file you are meant to edit. Anyone able to reach the VNC interface on 8006 or Remote Desktop on 3389 can attempt that login, and the loopback binding in the ports section is the only thing between them and a successful one. Change both values, as the file invites you to.

The second is the image reference. `ghcr.io/dockur/windows:latest` carries no version, and it belongs to the separate `dockur/windows` project, which `compose.yaml` points you to for documentation, the FAQ and additional configuration options. The consequence is that rebuilding can pull a different Windows image than the one your VM was created from, and this repository publishes no GitHub releases to pin against.

Only your Linux home crosses into Windows, as a redirected drive

One filesystem bridge is named: the GNU/Linux `/home` directory is accessible within Windows at the `\\tsclient\home` mount. That path shape comes from FreeRDP's client drive redirection, the same mechanism that carries the Remote Desktop session itself.

The consequence is directional and worth stating exactly. Files under your Linux home directory are visible to every Windows application you launch and to Windows itself, so anything you run inside that VM can read them. Anything on the Linux side outside `/home` is not covered by this, which means a checkout under `/opt` or `/srv`, or a service's data directory, will not appear on its own. You would be moving it under your home directory or finding another route.

Office deep links need a browser extension that reports you as Windows

Microsoft Office links such as `ms-word://` opened on the host are handled automatically, which reads like the tidiest corner of the integration. The project's own note is where the caveat sits. The Office web apps typically hide the "Open in Desktop App" option for Linux users, so reaching it may require installing a User Agent Switcher browser extension and setting the user agent to Windows.

Read that as a dependency rather than a convenience. The extension comes from a separate project and is not part of WinApps, and what it changes is not Office but how every site you visit identifies your browser. A user agent override is a blanket setting, and it will be inaccurate for the rest of the web while it stays on.

So the convenient deep-link path arrives with a browser-wide side effect. When you do not want that, the fallback is the host shortcut the project created for you, which is why the shortcut mechanism matters more than the protocol handler.

What the claim of universal application support actually covers

The README says WinApps supports all Windows applications, and then explains how that is achieved through two scans. It looks for applications on a community tested list, and separately it looks for any other `.exe` files listed within the Windows Registry.

The two groups are treated differently. Community tested applications come with high-resolution icons and pre-populated MIME types, and those MIME types are what let a file manager decide which Windows application should open a file based on its extension. Everything else that gets detected has its icon pulled from the `.exe` file itself.

So the claim means a shortcut will be created, not that an application has been verified to work. The project states that limit itself: the list is community-driven, and some applications on it may not be tested and verified by the WinApps team. The effect is concrete. An application with no entry gets a scraped icon and no MIME types, so your file manager will never offer it as the handler for a file type and you open it from the menu by hand. Entries such as Adobe Photoshop, listed against CS6, CC and 2022, are the ones that get the full treatment.

Kernel-level anti-cheat is the stated ceiling, and desktop scope is narrow

There is one exclusion stated outright: support does not extend to kernel-level anti-cheat systems, with Riot Vanguard named as the example. A title that requires one will refuse to run inside the virtual machine, and no amount of shortcut or MIME-type work changes that. It is the hard ceiling on the universal support claim, and the first thing to check if the application you want is a game.

Desktop coverage is narrower than the application claim. KDE Plasma, GNOME and XFCE are the three named, and the only file manager integration described is with `Nautilus`, which belongs to GNOME.

As a repository, it publishes no GitHub releases, so you track it as source rather than as a versioned download. The last push was on 2026-11-01. The root carries `LICENSE.md` and `COPYRIGHT.md` as two separate files, and the repository's licence field is recorded as unclassified rather than as a named licence, which is worth settling for yourself before you redistribute anything built with it.

Editorial conclusion

WinApps fits a Linux desktop user who needs one specific Windows application that has no native build, and who can spare four cores, 64G of disk and whatever memory a Windows VM wants. It does not fit someone expecting a light translation layer, a game with kernel-level anti-cheat, or right-click file integration beyond the Nautilus integration the README describes. Before the first boot, change USERNAME and PASSWORD in compose.yaml, since it ships MyWindowsUser and MyWindowsPassword in plaintext, and decide whether you can accept an image reference pinned to latest from another project's registry.

Frequently asked questions

Official sources

1. Issues
2. README
3. winapps-org/winapps on GitHub