Edge3 on Windows

[jmgallag]

Looking for clarification on Edge3 documentation regarding installation on Windows. Providers/edge3/docs/install_on_windows.rst is instructions for installing on Windows, yet this statement is near the top: It is known that due to changes in Task SDK running in Windows is not possible.

It seems contradictory.

[cookesan]

I would treat the Windows page as stale or at least version-limited for Airflow 3.

The page currently says all of these at once:

• Windows Edge Worker usage is experimental
• it is not validated in CI
• Linux is recommended
• the setup was tested with Airflow 2.10.5
• Task SDK changes make running on Windows not possible

For Airflow 3.x, the conservative answer is to run the Edge worker on Linux, WSL, or a container rather than native Windows. If you open a docs PR, I would make the page explicit that the Windows instructions are historical/2.10-era proof-of-concept material unless someone can provide a current Airflow 3 Windows test path.

[jmgallag]

Thanks for the reply. I received feedback elsewhere not to run Airflow under WSL... Having done more reading since then, the whole fork() issue makes it clear that some sort of a layer like WSL is needed.

I will give Edge3 under WSL a try.

My dilemma is that I need to orchestrate a COTS tool that the vendor only provides for Windows.

[cookesan]

That COTS constraint is the important part.

I would keep the Airflow/Edge runtime boundary on the Linux side first, then make the Windows-only tool a narrow task boundary. Microsoft documents WSL running Windows .exe tools from the Linux command line: https://learn.microsoft.com/en-us/windows/wsl/filesystems#run-windows-tools-from-linux

The useful smoke test is whether your exact vendor CLI behaves correctly there, not whether native Windows is a supported Airflow worker target. The current Edge3 docs still treat native Windows worker support as experimental/proof-of-concept and not current for Airflow 3, but the example DAG shape is useful: a dedicated windows queue and a small operator that shells out to one Windows process.

If the vendor tool needs GUI/session/licensing state, I would move that into a Windows-side wrapper script or service and have the Airflow task call that wrapper. The first test I would run is: can the Linux/WSL Edge worker invoke this vendor tool repeatably with the right identity, paths, exit code, and output artifacts?