Adding seamless Windows VM (with docker) launcher as native app

[sspaeti]

This is my implementation of a starting a Windows VM with one launcher command. Not sure if that is too heavy of a feature for Omarchy, but I thought I leave it here in case anybody would like or have the requirement to use an application that only runs on Windows. This way, we can quickly ramp up a VM with docker and connects via RDP, and automatically close when we close the Remote Desktop.

What's Added

• omarchy-launch-ms-windows - Smart launcher script that manages Windows docker container and connects via rdesktop
• Windows VM desktop entry - One-click access from application launcher
• Automatic container management - Handles startup, health checks, and cleanup
• Persistent storage - VM data stored in ~/.windows directory

Features

• One-click launch from application menu
• Health monitoring - Waits for container and RDP to be fully ready
• Auto-cleanup - VM shuts down when RDP session ends
• Smart container handling - Removes existing containers and starts fresh
• Integration with UWSM - Properly managed as Hyprland application

Requirements

• rdesktop - For RDP client connections
• netcat (nc) - For port availability checking
• curl - For web interface health checks
• Docker (already provided by Omarchy)

Technical Details

Uses the excellent dockur/windows Docker image which handles Windows 11 ISO download, installation, and configuration automatically. First-time setup takes 30-60 minutes for Windows installation, subsequent launches are much faster (a couple of seconds).

Demo: See a live demo: https://github.com/user-attachments/assets/f1fdfab6-d61a-4f91-a54c-50a975385a5d (if video work here, otherwise posted it here too: https://x.com/sspaeti/status/1961826772682490032)

Open

Things not finalized yet where I'd need help:

• there's no migration script yet as I didn't know if this features is wanted or not
• not sure if the relative path of icons/windows.png would work.
• I use a version with docker-compose (so i can customize), but thought I add only a light version with the one dockercommand here docker run -it --rm --name windows -p 8006:8006 --device=/dev/kvm --device=/dev/net/tun --cap-add NET_ADMIN -v "${PWD:-.}/windows:/storage" --stop-timeout 120 dockurr/windows. But couldn't test that. But the docker-compose version works well.

[rmacklin]

Not sure if that is too heavy of a feature for Omarchy

Probably depends if it runs Lightroom well

[bjarneo]

This idea is interesting. I really like it as some software can't run on Linux, yet.

It could be done running a docker instance of osx as well: https://github.com/sickcodes/Docker-OSX

[sspaeti]

Not sure if that is too heavy of a feature for Omarchy

Probably depends if it runs Lightroom well

I don't have an Adobe license, but I'd imagine it works. I'm running MS Word when editing some large word documents. Works like a charm, even the CPU/RAM usage is very consistent.

It could be done running a docker instance of osx as well: sickcodes/Docker-OSX

I saw that, indeed. I don't have that requirement, but we could set it up as well if anyone has macOS software, making the initial transition easier.

[bjarneo]

I did not add all the context I had in mind. I don't think osx needs to be part of this PR. Was more of a, cool, maybe something similar can be done for osx separately for those in need of that.

On Sun, 31 Aug 2025, 13:01 Simon Späti, @.***> wrote:

sspaeti left a comment (basecamp/omarchy#1333) https://github.com/basecamp/omarchy/pull/1333#issuecomment-3240050920

Not sure if that is too heavy of a feature for Omarchy

Probably depends if it runs Lightroom well

I don't have an Adobe license, but I'd imagine it works. I'm running MS Word when editing some large word documents. Works like a charm, even the CPU/RAM usage is very consistent.

It could be done running a docker instance of osx as well: sickcodes/Docker-OSX https://github.com/sickcodes/Docker-OSX

I saw that, indeed. I don't have that requirement, but we could set it up as well if anyone has macOS software, making the initial transition easier.

— Reply to this email directly, view it on GitHub https://github.com/basecamp/omarchy/pull/1333#issuecomment-3240050920, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAK2PTW45FEDGV5FVUXDZPD3QLIYDAVCNFSM6AAAAACFG56HWKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENBQGA2TAOJSGA . You are receiving this because you commented.Message ID: @.***>

[sspaeti]

Just for reference, there's another project that uses docker https://github.com/winapps-org/winapps, and they say Lightroom is supported -> so I guess it will work fine @rmacklin and @dhh :)

Thanks to k3nundrum from the Discord community.

[owensd]

This was great. I used your docker-compose version (with some modifications). This PR did not work for me, but your compose version, I was able to get up and running perfectly.

[geiman]

I was actually working on testing WinApps today on Omarchy. Haven't tested Lightroom yet, but gave Photoshop a try. Wasn't really usable in it's current form in my opinion. Menus and other UI elements show up blurry 50-75% of the time for some reason, and manipulating elements in a project was very difficult. Guessing it's something with how Hyprland renders the window. Using this bind to disable the blur doesn't seem to do anything to help:

https://github.com/basecamp/omarchy/issues/1295

I'm guessing Lightroom will be the same.

But O365 apps work great - Word, Excel, PowerPoint and Outlook all functioned fine. Haven't tested Teams yet, but I imagine it will be fine.

[sspaeti]

@geiman thanks for the test and update here. Same findings, Word/Excel work very well. Teams I use native, no need for Windows on this one IMO.

Interesting with the Adobe products. I don't have the time to test this, but eventually I'll give it a try too (if there's a trial version).

[TyRichards]

Yep I neeeeed this for Illustrator and Lightroom.

[sspaeti]

This was great. I used your docker-compose version (with some modifications). This PR did not work for me, but your compose version, I was able to get up and running perfectly.

This might be the case that I'd need to add the docker-compose version - thanks for the feedback. I wasn't sure where to put the docker-compose file in the Omarchy configuration - but if DHH gives the OK that he wants this, I will make it happen.

I have a sense it's too much of a setup for him. But happy do change if it's useful or wanted.

[dhh]

This is really interesting! It's still setting up for me, but a few notes: It needed gnu-netcat and rdesktop packages installed. So will need to omarchy-pkg-add those. Then it started the remote session http://127.0.0.1:8006/, but I had to go there myself. We should have a web app that's automatically wrapping and starting that.

[dhh]

Hmm, this entire install doesn't seem to ask for a windows license key anywhere? We can't have anything in Omarchy that's skirting licensing terms of Windows.

[sspaeti]

Update: I changed the setup to use a proper docker-compose.yml as this seem to work better (https://github.com/basecamp/omarchy/pull/1333#issuecomment-3247247356, I also use this version), plus it's easier to add parameters such as CPU or MEMORY or the windows KEY.

One thing I'm unsure - we have two different modes that you also ran into it:

1. initial install. It takes a while until it downloads everything and installs all. This can be done with docker compose up.
2. once everything is installs initially, the added desktop app applications/windows-vm.desktop in combination with the bin/omarchy-launch-ms-windows will handle the automatically starting docker compose and once ready connect via Rdesktop. See demo here once it is installed: https://x.com/sspaeti/status/1961826772682490032

But should we have a bin/omarchy-install-ms-windows script that does the installation? In theory, it will also install the docker container when you run the desktop app, but it's not that transparent, and if something goes wrong, you need to check http://127.0.0.1:8006/. So not sure what the best "workflow" for that is.

Happy to get feedback. But I think it's not far away to be super useful to people.

[sspaeti]

OK, I added the installation within the bash script bin/omarchy-launch-ms-windows and added the wrong KEY to prompt during installation, which looks like this:

You can then fill in your key (or a dev key as the https://github.com/dockur/windows is using as default: https://gist.github.com/rvrsh3ll/0810c6ed60e44cf7932e4fbae25880df#kms-client-product-keys)

[dhh]

That's great. Feel much better about that!

In terms of setup, I'd do Install > Windows to setup the docker stuff and then make the docker stuff persistent across reboots by default. And then we add Windows WM as a webapp against localhost:8006 in that install setup too. Need to add Remove > Windows too then.

[sspaeti]

And then we add Windows WM as a webapp against localhost:8006 in that install setup too.

I'd not use a web-app, but a desktop app, no? The rdesktop is a remote desktop connections that looks much better than the web version on http://localhost:8006 (webapp). So I'd use my provided desktop-app applications/windows-vm.desktop that does that and also automatically opens and close the docker-container on quitting the rdesktop. At least that would be my suggestion.

In terms of setup, I'd do Install > Windows to setup the docker stuff and then make the docker stuff persistent across reboots by default. Need to add Remove > Windows too then.

This is a great idea. I need to look into how this is done on other apps.

[dhh]

Ahh, my bad. I thought it was just accessible through the webapp!

[sspaeti]

Alright, now it should be a quite nice workflow.

Install

The installation process will do these steps:

1. download the docker image and installing it
2. open the browser to follow along the installation (this can take 10-15 min)
3. requests a product-key for windows unless not specifies in docker-compose under KEY
4. installs desktop app and icons
5. Manually quit the window with SUPER+W when windows is installed (needed as there is no clear thing when finished), this quitting will automatically stop the docker container.

From that point on, installation is done and we can use walker-launcher below.

Launch

After that, it can be simply launched the Windows VM which does:

1. start docker container
2. waits until port for RCP is ready and connects hard-coded resoluton 1920x1200 (should we do a config for this?)
3. and automatically stops docker container on SUPER + W on rdesktop app.

Remove

Under remove, we can remove everything, including

1. installed two packages redesktop and netcat,
2. and it prompts if VMs should be removed too (data) under ~/.windows
3. also application and icons is removed too.

Remaining Questions

I think other than this remaingin questions, it's ready IMO:

1. where do you usually copy desktop apps to? currently applications/windows-vm.desktop is moved to /usr/share/applications/windows-vm.desktop correct?
2. do you like naming of Windows VM?
3. And is under installation as it's own point the correct place to put it?

@dhh Wdyt?

PS: sometimes the first try needs a manual rdesktop connect to accept the initial certificate - this can be done by launching the app and the run rdesktop -g 1920x1200 -u docker 127.0.0.1:3389 -p admin and confirm with yes. After that it will work when docker container is stopped again.

I tried to handle it in bin/omarchy-install-windows-vm but I'm not a 100% clear if it works on a totally new instance:

[dhh]

We should copy the .desktop file to ~/.local/share/applications. That's where the other Omarchy ones are.

I think we can just go with "Windows" instead of "Windows WM". I like it under install 👌

We def need to test that the out-of-the-box is totally smooth.

This seems super promising!

[sspaeti]

OK done. And yes, please, I'd be happy if someone could test it sorrowly and give feedback.

[ryanrhughes]

@dhh in thinking about this; couple of conceptual considerations we should probably weigh here:

• We copy all .desktop files in install/config/mimetypes.sh which would bring this in without having installed it
• The omarchy-launch-windows-vm would also be a bin available without actually functioning and need error handling.

We could either have it available right from the start; in which case omarchy-launch-windows-vm should have a gate to make sure that we can reasonably assume the install has been ran and will have a successful launch, otherwise throw an option to run the install.

This route also kind of removes the need for an option in the install menu since it'd be kind of an implicit path on first execution.

If we don't want to show it at all unless people install it, I think I'd probably suggest we remove the .desktop file and have the installer write the file using tee so it only exists after install. The icon is fine and doesn't cause any real issue.

[sspaeti]

Quick update:

Based on this video I tested freeRDP for remote desktop connection, and it seems to work better. The mouse for example is consistently showing when I work in Microsoft Word (in Rdesktop it was hiding the mouse and only showed when I clicked). They also mention that Adobe and other tools are supported, so it might work better with this.

It can be installed with sudo pacman -S freerdp and launched in full screen with xfreerdp3 /u:docker /p:admin /v:127.0.0.1:3389 /size:1600x1000 /f. I will test a bit more, but when this stays like this, I will change the RDP tool to freeRDP.

It seems also to have a certificate handler, which would solve the problem that currently potentially still exists on first connect, that you need to manually accept - from their help:

    /cert: [deny,ignore,name:<name>,tofu,fingerprint:<hash>:<hash as hex>[,
           fingerprint:<hash>:<another hash>]]
                                      Certificate accept options. Use with
                                      care!

                                       * deny         ... Automatically abort
                                      connection if the certificate does not
                                      match, no user interaction.

                                       * ignore       ... Ignore the
                                      certificate checks altogether (overrules
                                      all other options)

                                       * name         ... Use the alternate
                                      <name> instead of the certificate subject
                                      to match locally stored certificates

                                       * tofu         ... Accept certificate
                                      unconditionally on first connect and deny
                                      on subsequent connections if the
                                      certificate does not match

                                       * fingerprints ... A list of certificate
                                      hashes that are accepted unconditionally
                                      for a connection

So we can use /cert:tofu with full connect ~/.l/sh/applications master *1 !4 ?1 ❯ xfreerdp3 /u:docker /p:admin /v:127.0.0.1:3389 /size:1600x1000 +f /cert:tofu.

Update: Working version I use is here: https://github.com/sspaeti/dotfiles/blob/master/hypr/.config/hypr/sspaeti/windows-ms/start-windows.sh

Update 2: I switched to FreeRDC as seen in the commits below as it works much better (and added ignoring certificates to avoid error on first connect).

[rCirelli]

Hey everyone. This is an amazing feature! I have a few considerations you may find valid.

When you start Windows either using omarchy-launch-windows-vm or from Walker, it opens a full-screen window after a few seconds, and I think this behavior could happen only when launching from Walker.

There could be a flag or something that allows me to launch Windows from the terminal, detached and without it opening in full-screen. So I could simply access localhost:8006 to use it. Another reason for that is when I close Windows the container automatically stops (which is expected), but every time I need to use it again (which happens sporadically throughout the day) I need to wait for the container and windows to load again. When I could keep the container running and simply access localhost:8006 every time I need to use it.

Also, when launched from Walker, in the few seconds it takes to open the full-screen window (which may vary from machine to machine) there's no feedback that anything is happening. Maybe a simple dialog could appear saying "Windows container starting, please wait" or something like that.

Lastly, is it possible to make the window that opens automatically scale the resolution dynamically? So when not in full-screen it does not clip the bottom of the Windows sceen:

I hope this can be useful to help improve this already great feature.

[subzelo]

Could Windows applications be integrated directly into the application launcher, similar to how WinApps works?

[sspaeti]

When you start Windows either using omarchy-launch-windows-vm or from Walker, it opens a full-screen window after a few seconds, and I think this behavior could happen only when launching from Walker.

Lastly, is it possible to make the window that opens automatically scale the resolution dynamically? So when not in full-screen it does not clip the bottom of the Windows sceen:

The fullscreen is +f, which can be removed when connecting. Also, the resolution is hard-coded at the moment with this command:

RDP_COMMAND="xfreerdp3 /u:docker /p:admin /v:127.0.0.1:3389 /size:1920x1200 /scale:140" +f -grab-keyboard /cert:ignore"

This can be customized, e.g. I changed mine to /size:1600x1000 /scale:140". This could be a variable, or read from hypr monitors, but I'm afraid that it might get too complex and not always work. Especially what if you have two or more screens, which one do we choose? Might be much easier to just customize it once in your configs, and then it will work (?) 🤔

So I could simply access localhost:8006 to use it. The web access on port 8006 is only for checking or troubleshoot, for using, you use RDC on port 3389, much better quality.

Another reason for that is when I close Windows the container automatically stops (which is expected), but every time I need to use it again (which happens sporadically throughout the day) I need to wait for the container and windows to load again

Fair point. To avoid this, we could also just keep the container running and have another command to turn on/off Windows VM, and the launch would just connect the RDC? But I don't like on my machine to have a docker container running, that uses lots of RAM/CPU, better to quickly restart.

there's no feedback that anything is happening. Maybe a simple dialog could appear saying "Windows container starting, please wait"

Good point. I think once we merge it, we could always update and work on smaller details. To me, most important that it works reliable and people can use Windows as simple and easy as possible.

[3bit]

Have you considered using WinBoat for this feature? https://www.winboat.app/ https://github.com/TibixDev/winboat

Winboat adds many benefits over a simple (Docker) Windows VM, like running single Windows applications (via RDP), filesystem integration, automated installs, smartcard and USB passthrough and more.

[sspaeti]

Have you considered using WinBoat for this feature? winboat.app TibixDev/winboat

Winboat adds many benefits over a simple (Docker) Windows VM, like running single Windows applications (via RDP), filesystem integration, automated installs, smartcard and USB passthrough and more.

I have seen it. It seems very experimental at this point and a little more overhead. I probably create a separate PR for trying it. As this PR is running Windows in a docker and connect via RDC to the container. Winboats uses some intermediate SW to handle stuff between the same docker container (they also use dockur container) and the FreeRDP (also what I use).

The questions would be: do we want this additional tool (might be nice to control and set some settings visually):

But on the other hand, it could also be seen as an overhead. I leave it up to @dhh to decide in what direction this PR should go, and take it from there. For me, I use this PR version for a while now, and it works great (mainly MS Office, Win explorer, PDF) as full-screen Windows on desktop 5. But I'm curious to try Winboat at some time.

[sspaeti]

I'm closing this, as all the commits went into this PR and Ryan improved off it and got it over the finish line: https://github.com/basecamp/omarchy/pull/2462. Thanks so much.