WinBoat: Windows apps as Linux windows, through RDP and a Docker VM

An Electron shell around a containerized Windows VM

The description line is Windows for Penguins, run Windows apps on Linux with integration into your desktop environment. The How Does It Work section is more useful than that line. WinBoat is an Electron app that runs Windows apps on Linux using a containerized approach. Windows runs as a virtual machine inside a Docker or Podman container. The app talks to that Windows install through a separate component called the WinBoat Guest Server, which lives in its own repository and exists to retrieve data the frontend needs.

The compositing part is where the interesting work is. FreeRDP is used together with Windows's RemoteApp protocol, which is the feature that lets a remote machine publish one application rather than its whole desktop. That distinction is the whole product: the feature list claims you can access the complete Windows desktop when you need it, or run individual apps as native OS-level windows, and the second mode is the one that makes the first one bearable.

The repository tree matches that story. `guest_server/` is the in-VM half, `src/` is the Electron frontend, `data/` and `scripts/` hold build and runtime material, `build-guest-server.sh` is the step that compiles the in-VM binary for the host, and `electron-builder.json` produces the four Linux packages. The `patches/` directory is a detail worth noticing: it usually means dependency patches are carried rather than contributed upstream.

Prerequisites that decide whether this works at all

The requirements list is the first thing to read, because it eliminates more machines than the feature list attracts. At least 4 GB of RAM, at least 2 CPU threads, at least 32 GB of free space on the drive your chosen install folder lives on, and KVM enabled in BIOS or UEFI.

On the container side, the Docker path wants Docker, Docker Compose v2, and your user added to the `docker` group. The Compose v2 requirement is not cosmetic: it is stated as required for compatibility with the compose files the project ships. Docker Desktop is explicitly not supported, with the README warning that you will run into issues if you use it, and the known-issues section repeats it as a container runtime limitation.

The Podman path has its own constraint. On Debian, Ubuntu and forks, the Podman version installed with `apt install` could be too old, and you need version 4.x.x or higher for the installation to complete. Podman Compose is required there for the same compose file compatibility reason. USB passthrough via Podman is listed as unsupported.

Then there is FreeRDP, which is easy to overlook because it sits under the runtime options rather than the container options. You need version 3.x.x with sound support included. The optional layer is the `iptables` or `nftables` kernel modules, which can be loaded for better network performance but are not obligatory in newer versions of WinBoat. The theme running through all of this: every runtime dependency has a specific version floor, and the beta warning at the top exists because those floors move.

Building from source with Bun and Go

Released builds are offered as four Linux variants. An AppImage, described as a portable format that should run fine on most distributions. An Unpacked variant, which is the raw files, run with `linux-unpacked/winboat`. A `.deb` for Debian-based distributions. An `.rpm` for Fedora-based distributions. There is also a Nixpkgs route, which needs the unstable channel and two configuration lines:

virtualisation.docker.enable = true;
users.users.{yourUser}.extraGroups = ["docker"];

Those two lines are the whole Nix setup, and they say something important: WinBoat is expected to run with access to the Docker socket, so a container without host container access cannot run it.

Building from source needs Bun and Go. The sequence is short enough to be worth quoting rather than paraphrasing:

git clone https://github.com/TibixDev/WinBoat
bun i
bun run build:linux-gs

After that, the built app is under `dist` with an AppImage and an Unpacked variant. In development mode the sequence splits the combined build into separate steps: `bun run build:gs` builds just the guest server, and `bun run dev` starts the app. The `package.json` scripts confirm the shape of that, with `build:gs` pointing at `bash build-guest-server.sh`, `dev` at `bun scripts/dev-server.ts`, and `build:linux-gs` chaining the guest build, `bun scripts/build.ts` and `electron-builder --linux`.

One oddity to expect in the dependencies. The package metadata declares engines of Node 23.6.0 or newer and Bun 1.3.0 or newer, and `package.json` still records version 0.9.0 while the release feed carries v0.9.1 and v0.9.2. The released build, not the manifest, is the number to trust.

What the 0.9 line fixed, and what 1.0 is holding back

The release notes are unusually informative, which is helpful for a project that tells you to expect hiccups. Versions 0.9.1 and 0.9.2 are both described as the final release of WinBoat 0.9, containing only security patches and other minor fixes, and both carry the same four security entries.

The first is the one that matters most: a flaw that allowed attackers to execute arbitrary PS1 commands inside the VM by calling get-icon with specific parameters. The second restricts icon lookup paths to prevent remote UNC access and reject control characters. The third prevents Slowloris-like attacks by restricting the header read timeout. The fourth stops passwords from being logged in compose and FreeRDP logs. The notes credit a reporter by name and say the fix landed within four hours of first contact.

So the icon lookup path was both the code execution bug and the UNC access bug, which tells you something about how the app surface was being audited. If you are running 0.9, treat the get-icon path as the reason to upgrade rather than as a curiosity.

The 0.9.0 release is the feature one, and its list explains what 0.9 was. Podman support arrived, without USB passthrough on Podman. UWP app support landed, so UWP apps show up and can be started. A Custom App can be created from an existing one for modification. Apps can be filtered and launched from the context menu. Application scaling became adjustable in Configuration, as did FreeRDP arguments. A `wm-class` prefix was added for styling WinBoat windows in a window manager. New installations reserve the port range `47270` to `47370` on Docker to avoid conflicts, while Podman, which does not support port ranges in compose files, gets random ports instead. The default install path became `~/winboat`, and Windows now synchronizes the clock on new installations.

The minor changes in the patch releases are also visible: Electron bumped to 44, dockur/windows to 6.05, and the profile picture became a local file.

Filesystem integration and the apps that justify it

The feature that does the most work per unit of effort is filesystem integration: your home directory is mounted in Windows, so file sharing between the two systems needs no copy step. For the common case of opening a document that arrived by email in a Windows application, that removes the entire friction argument against running Windows software.

The feature list also names a full Windows desktop mode, resource monitoring, and smartcard passthrough, with the note that more features are being added regularly. The Windows apps themselves are launched through the guest server, which is what the README describes as retrieving data the frontend needs from Windows.

There is a licensing dimension worth being blunt about. Because this is a full Windows installation inside a virtual machine rather than Wine translating Windows calls to Linux libraries, you need a Windows license in the way you would on any other machine, and the resource cost is a real VM rather than a compatibility layer. That is the honest comparison with Wine: Wine reuses your Linux system and translates the API, so it is cheaper and lighter where it works; WinBoat boots a real Windows and gets real behavior, so it costs RAM, disk, and a licensing decision. Which one is better depends entirely on whether the application you need runs correctly under translation.

Beta status, repository locations, and where to start

The status warning is not buried. WinBoat is currently in beta, so expect to occasionally run into hiccups and bugs, and you should be comfortable with some level of troubleshooting if you decide to try it, though the project still encourages you to give it a shot. With 297 open issues, that expectation is calibrated rather than reassuring.

There is also a repository-location wrinkle that will confuse you if you type what you find in the README into a browser. The files in this repository link their clone URL and their package metadata to `github.com/TibixDev/winboat`, while the repository is hosted under the `winboat-org` organization, and the releases tab link points at the TibixDev path as well. Both facts are visible in the project's own metadata, and the practical reading is that the organization is the canonical home while the individual account is where the links were written. If you are looking for the guest server, the README links a separate `TibixDev/winboat` guest server tree, which is the in-VM half and is a distinct deployment target.

The project homepage is `winboat.app`, the license is MIT, the default branch is `main`, and the last push was on 2026-09-18. GPU acceleration is what the 0.9 notes promise for 1.0, which is the single feature that would most change the calculus for graphics-adjacent applications.

The contribution rules are also specific. Technical contributions are the focus, and pull requests containing political or sexual content or other sensitive topics will not be accepted.

Editorial conclusion

WinBoat is the right shape of answer for one specific job: running a handful of Windows programs that have no Linux build, without giving up your Linux desktop, your window manager and your file layout. The dependency list is the honest test of whether it fits your machine, and it is not light: KVM in firmware, at least 4 GB of RAM, 32 GB of free space, a container runtime, and a FreeRDP build with sound. Docker Desktop is unsupported outright, and the project says so twice. What you give up is licensing convenience, since the VM runs a full Windows install, and what you gain is that the app behaves like Windows rather than like an approximation of it. Start with the AppImage, check that your firmware exposes KVM, and read the container runtime section before you install anything.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. winboat-org/winboat on GitHub