NEWS
WinBoat Runs Windows Apps on Linux by Booting Windows
WinBoat puts Adobe, Office and Affinity on the Linux desktop by running a real Windows VM in Docker, then asking you for a license key.
WinBoat showed internal DirectX 12 GPU acceleration on September 9, 2026, while public downloads remain on the 0.9.2 beta. The Linux app still runs a real Windows virtual machine inside Docker or Podman and paints each program as a normal desktop window through FreeRDP.
Version 1.0 is being built in public on a bleeding-edge branch. The wager is that shared-host graphics will make Adobe, CAD, and Office usable without dual-boot, after Wine spent decades reimplementing Windows APIs and still dropping the suites this project was started to run.
The 0.9.2 Beta on the Download Page
The current WinBoat Linux downloads still point at v0.9.2, tagged on August 25, 2026. The site calls the app beta and says you should be ready to troubleshoot. AppImage,.deb,.rpm, an unpacked binary, and a nixpkgs-unstable package are the shipping forms. MIT license. Maintainer Tibix (GitHub: TibixDev), a full-stack engineer in Romania, lists the project as his current work.
WINBOAT IN NUMBERS
- GitHub stars: 22.8k on the winboat-org/winboat repo, with 730 forks.
- Public tag: v0.9.2 on August 25, 2026, billed as the last 0.9 release.
- Commits since that tag: 86 on main, plus a 1.0-bleeding-edge branch touched on September 9, 2026.
- Hardware floor: 4 GB of RAM, 2 CPU threads, 32 GB free on the install drive, and KVM on in BIOS or UEFI.
The contributing guide says tens of thousands of people use the app every day. That is the project’s own count, not an audited install figure, and it sits next to a star chart that would be large for a tool that still asks you to enable virtualization and join the docker group.
0.9.2 is a security and housekeeping cut, not a graphics cut. Electron moved to 44. The Windows image underneath moved to dockur/windows 6.05. Passwords stopped landing in compose and FreeRDP logs. AndreaBonn reported a guest-server flaw that let callers run arbitrary PowerShell inside the VM through get-icon; the notes say it was patched within 4 hours of first contact, with extra limits on icon paths and header-read timeouts.
THE 0.9.2 SECURITY PATCHES
- get-icon: Callers could no longer smuggle PowerShell into the VM through crafted icon requests.
- Icon paths: Lookup is confined, remote UNC paths are blocked, and control characters are rejected.
- Slow reads: Header timeouts were added to blunt Slowloris-style stalls.
- Secrets in logs: Compose and FreeRDP logs no longer print the Windows password.
The same notes close with the line the rest of this story hangs on. “This is the final release of WinBoat 0.9, it only contains security patches and other minor fixes. Stay tuned for 1.0, we’re excited to ship GPU acceleration and other cool things.”
How WinBoat Puts a Windows App on a Linux Desktop
WinBoat is an Electron app and guest server that starts a Windows VM in a container, talks to a small agent inside that VM, and uses FreeRDP with Windows RemoteApp so each program appears as its own Linux window. Your home directory is mounted into Windows. A full Windows desktop is still there if you want it. FreeRDP has to be 3.x.x with sound.
That is a different bet from Wine. Wine translates Windows API calls into Linux calls and needs no Microsoft key. WinBoat boots real Windows, so the installer that refuses Wine is no longer a research project. You also inherit Windows Update, antivirus, disk, and a license key. The default ISOs are trial images, the same class of file you would pull from Microsoft, and the FAQ is blunt that the project does not activate Windows for you.
Setup is the product. Pick RAM, CPU, and disk in the GUI and the app writes compose, pulls the image, and waits out the unattended install. Docker Desktop is unsupported; you want the engine, the v2 compose plugin, a user in the docker group, and a daemon that starts on boot. The Docker Engine install guide is the path the project points at. From v0.9.0, tagged November 23, 2025, you can pick Podman instead, at Podman on Linux docs version 4.x.x or newer, with USB passthrough still missing on that backend.
New installs reserve Docker ports 47270 to 47370 so the guest server, RDP, and helpers stop colliding with common host ports. Podman cannot declare that range in compose, so it draws random ports. USB passthrough arrived as an experimental Docker feature in v0.8.0 on September 17, 2025. Smartcard passthrough and a resource monitor are in the shipping client. Flatpak is on the list and not done, because the sandbox would have to see installed apps, the Docker or Podman binary, and the container socket.
dockur/windows Does the Heavy Lifting
The VM is not a WinBoat original. Under the app sits dockur/windows, the widely starred project that puts Windows inside a Docker container. That repo holds 53.2k GitHub stars. Its README tells people who want a graphical desktop to look at WinBoat, WinPodX, or WinApps, and it says each of those projects uses this container as its backend.
dockur handles ISO fetch, unattended setup, KVM, ballooning RAM, USB, and folder shares. Defaults there are 2 CPU cores, 4 GB of RAM (the same figure as WinBoat’s minimum, used here as the image’s stock allotment), and a 64 GB disk, which is a different floor from WinBoat’s 32 GB of free space. Pick VERSION=11 and you get Windows 11 Pro, a 7.9 GB download on dockur’s own table. The same image family still offers 10, LTSC, Enterprise, and a graveyard of older clients.
WinBoat’s job is the part dockur does not sell: a guest agent, an app catalog, RemoteApp windowing, USB that does not mean editing compose by hand after 0.8.0, and an installer a non-sysadmin can finish. WinApps, which started around 2020, still offers Docker, Podman, and libvirt and expects config files. WinPodX showed up later as another frontend on the same image. WinBoat is the one with the guided GUI and the 22.8k-star consumer face.
README credits also name Cassowary as a related idea. The pattern is now a small product category: Windows as a sidecar container on a Linux box, with three desktops competing to make that sidecar feel like a normal app.
Office, Adobe, and the Apps Wine Will Not Run
WinBoat’s FAQ does not pitch itself against games. It lists the programs that pushed the authors off Wine: Affinity Photo, Paint Tool SAI v1.0, the Adobe suite, AeroChat, Acrobat, and Office. “You can run stuff that doesn’t play well with CrossOver or WINE, and have a full Windows desktop at the same time,” the FAQ says. Office 365 is an explicit yes.
That list is the whole wager, and it is already under pressure. Affinity v2, the Canva-era single app, now runs on stock Wine 10.17+ according to the Affinity-on-Linux packaging work, so one of WinBoat’s original exhibits has a lighter path. Games with working Proton builds never belonged here. Kernel anti-cheat titles are out on both stacks, because those anti-cheat systems block virtualization and Wine is not a full Windows kernel either.
What remains is the software that still wants a real Windows user-mode stack, a Microsoft Store or UWP install, or a vendor installer that Wine has not finished. That is current Office, most of Adobe, device utilities that ship only as Windows EXEs, and CAD codes that expect DirectX. Those programs are why a 4 GB VM with a 32 GB disk is worth the RAM.
THREE WAYS TO GET A WINDOWS APP
| Approach | What actually runs | Windows key | GPU on the build you can download |
|---|---|---|---|
| Wine / Proton | Only apps the translation layer supports | Not required | Often, when the app is supported |
| WinBoat 0.9.2 | Real Windows, each app as a Linux window | You supply a key to activate | No |
| WinBoat 1.0 bleeding edge | The same VM model | You supply a key to activate | DirectX 12, very alpha, compile it yourself |
Hands-on writeups keep landing on the same split. Wine is lighter and already fine for a long tail of older EXEs. The container path wins when the installer will not start in Wine. Nobody serious is using this as a Steam replacement.
DirectX 12 Acceleration Landed Inside the Lab
The public FAQ on winboat.app still answers “Is there GPU acceleration/passthrough?” with “Not at the moment.” On September 9, 2026, the official account posted a six-part update that the FAQ has not absorbed.
DirectX 12 GPU acceleration (very alpha) has been achieved internally (1/6)
Massive thanks to @rupansh_1 for the driver development effort and bearing with me for the last couple months pic.twitter.com/sjJmSvpGqI
— winboat.app (@winboat_app) September 9, 2026
DirectX 12 GPU acceleration (very alpha) has been achieved internally (1/6). Massive thanks to @rupansh_1 for the driver development effort and bearing with me for the last couple months
WinBoat, official account, on X
Release timing in part two is “Before 2027 hopefully,” with public test builds hoped for much sooner and private GPU QA builds already with a test group. Part five says you can compile 1.0-bleeding-edge yourself if you want a “mega-unstable-alpha-work-in-progress” that “is not representative of the final product.” Part six adds shortcut support on that same branch.
The next morning the account had to correct the most common misread. This is not passing a whole GPU into the VM. “It’s not passthrough, it’s acceleration, so your GPU stays on your Linux host while Windows can benefit from it.” A follow-up named the mechanism: paravirtualization on the Venus protocol and virglrenderer. The host keeps the card; Windows gets a virtual GPU that forwards work.
That matches the older lab trail. In October 2025 the same account showed Autodesk Fusion on an OpenGL backend after porting MVisor’s VGPU device to QEMU, and Direct3D 11 through WineD3D on the same shared card. The site FAQ still points at MVisor’s Win VGPU driver as promising but built for a different hypervisor, and at Looking Glass’s Indirect Display Driver as a future display path that compiled, started, and then showed a black screen. Looking Glass, if it ever lands, is display streaming, not this GPU work.
WHAT WE KNOW
- DX12 status: Achieved internally on September 9, 2026, labelled very alpha.
- Who can run it: A private GPU QA group, plus anyone who compiles 1.0-bleeding-edge.
- Mechanism: Shared-host acceleration via Venus and virglrenderer, not SR-IOV passthrough.
WHAT IS UNCONFIRMED
- Ship date: Public tests “much sooner” than a 1.0 that is only hoped for before 2027.
- Hardware matrix: Nvidia hosts, older Intel iGPUs, and Vulkan were the first questions and have no published yes.
- App quality: No public list of Adobe, Office, or CAD titles running at usable frame times on this path.
CAD users have been asking for this since the first months of the beta, including Solid Edge and Fusion, because software rendering makes those tools crawl. Until a public 1.0 build exists, those people are still on dual-boot or a second GPU passed into a classic VM.
What Still Breaks on the Stable Build
On 0.9.2, graphics-heavy apps run, but they run on the CPU. Kernel anti-cheat games refuse the VM. Docker Desktop still fails. USB passthrough is Docker-only. You still need a Windows key if you want an activated guest, and you still need FreeRDP 3 with sound, KVM, and 32 GB free. The beta warning on the download page is not decoration.
HARD LIMITS ON 0.9.2
- No public GPU: Paravirtualized acceleration is 1.0 work, not the August 25 build.
- Anti-cheat: Titles that block virtualization will not run.
- License: Trial ISOs only; bring your own key.
- Podman USB: Unsupported, even though Podman itself shipped in v0.9.0.
- Docker Desktop: Explicitly unsupported on Linux for this stack.
- Flatpak: Still a to-do because the sandbox hides the container socket.
Those limits define the buyer. If Wine already runs the one EXE you need, skip the VM. If you live in Photoshop, Inventor, or desktop Microsoft 365 and you can spare RAM and disk, the sidecar is the honest compatibility story on Linux in 2026, with the speed story still in the lab.
The 1.0 Branch Asks You to Compile It Yourself
Main is not idle. A config-load fix for RDP arguments landed on September 8, 2026. The 1.0-bleeding-edge branch moved on September 9, the same day as the DirectX 12 post. Building from source wants Bun and Go, then bun run build:linux-gs for the app and the guest server. That compile step is being used as a filter so unfinished graphics do not hit the AppImage channel.
THE ROAD TO 1.0
- September 17, 2025: v0.8.0 ships experimental dynamic USB passthrough on Docker.
- November 23, 2025: v0.9.0 adds Podman, UWP apps, scaling controls, and the 47270-47370 Docker port range.
- August 25, 2026: v0.9.2 closes 0.9 with the get-icon fix and a public promise of GPU in 1.0.
- September 9, 2026: DirectX 12 acceleration is shown internally; 1.0-bleeding-edge is the only way to touch it.
The downloadable file is still 0.9.2. The bet sits on a branch you have to build, a driver from rupansh_1, and a 1.0 the project will only promise as “before 2027 hopefully.”
-
NEWS4 months agoThe Orchard Bug Forced Zcash to Open an Empty Pool
-
GAMING4 months agoThe $5.99 Game That Won Steam’s 2026 Summer Sale
-
ENTERTAINMENT6 months agoDon Lee Joins Hemsworth as Extraction 3 Starts Shooting
-
NEWS4 months agoYouTube Shorts Retires Dislikes and Swaps Likes for Hearts
-
NEWS4 months agoNEURA Robotics Is Spending Its $1.4B on a Machine Stack
-
AUTO6 months agoKawasaki Bets the New Z1100 Against Its Own Supercharger
-
BUSINESS5 months agoNorway’s Export Bank Backs Nscale’s $790 Million Narvik Loan
-
GAMING4 months agoGame of Thrones Dragonfire Follows Boston’s Conquest Playbook
