Virtual Desktops (Windows)

The image create form with Windows selected as the desktop OS, showing the edition dropdown, username and password fields, keyboard layout, and system language.

Trailer can run a full Windows virtual desktop inside a workspace. A Windows VDI workspace boots a real Windows VM and gives you a browser-based desktop, with the same workspace lifecycle, networking, and volumes as any other workspace.

Windows desktops run as a virtual machine inside the container, so they require a host that supports hardware virtualization. They are available on the Docker runtime backend.

How it works

Trailer publishes prebaked Windows disk images. When you create a Windows VDI image, Trailer personalizes one of these disks with your edition, account, language, and any files you upload. It does not reinstall Windows, so builds are fast.

At runtime the workspace boots the disk image in a virtual machine and serves a noVNC web desktop on container port 8006.

Windows VDI images do not install applications at build time. The desktop application and general application lists that Linux images offer do not apply here. Python packages and environments are still supported. Trailer resolves and installs them with pixi the first time the Windows desktop boots, so that first boot takes a little longer than later ones.

Creating a Windows desktop

A Windows desktop starts as an image, then you launch a workspace from it.

1. Create a new image and set the desktop OS to Windows.
2. Pick an edition (see below).
3. Set the username and password for the Windows account.
4. Choose a keyboard layout and system language.
5. Optionally upload files to inject into the disk (see File injection).
6. Build the image, then create a workspace from it.

When you create a workspace from a Windows VDI image, Trailer prefills sensible defaults: hardware acceleration on, nested virtualization on, and a Virtual Desktop URL pointing at port 8006. You can override any of these before launching.

Editions

The edition maps to a tag of ghcr.io/trailer-dev/windows. The supported editions are:

Edition	Description
11	Windows 11 Pro
11l	Windows 11 LTSC
11e	Windows 11 Enterprise
10	Windows 10 Pro
10l	Windows 10 LTSC
10e	Windows 10 Enterprise
2025	Windows Server 2025
2022	Windows Server 2022

Account and localization

• Username: the local administrator account created during first boot. Required.
• Password: typed into the image form. It is stored in a hidden column and never returned by the API. When a password is already set, the form shows a “set, type to change” hint. Leaving it blank on edit keeps the existing value.
• Keyboard layout: the input layout applied inside Windows (for example US, UK, German, French).
• System language: the display and system locale (for example en_US.UTF-8, de_DE.UTF-8).

Accessing the desktop

The Windows desktop is served as a noVNC web viewer on container port 8006. The workspace gets a Virtual Desktop URL on the desktop subdomain pointing at that port, so you open the desktop straight from the browser.

For RDP, the VM forwards port 3389 automatically. To reach it from outside the container, publish a port binding for 3389/tcp on the workspace. RDP cannot be proxied through a URL, so it needs a direct port binding.

Hardware acceleration and nested virtualization

Two workspace toggles affect Windows VMs. Both are pre-enabled when you create a workspace from a Windows VDI image:

• Hardware acceleration: passes GPU devices into the VM.
• Nested virtualization: attaches /dev/kvm so the VM can use KVM acceleration. Without a usable /dev/kvm, the VM cannot use KVM acceleration.

These require matching host support. If the host has no GPU or no KVM, turn the corresponding toggle off.

Exposed ports

For a workspace on a bridge network (the default), any port you publish, and any URL you define, is forwarded from the container into the Windows VM automatically. You do not need to configure the VM’s networking by hand. The desktop web port (8006) is served by the container itself and is never forwarded.

When a macvlan network is attached, the VM bridges directly onto the LAN and picks up its own address by DHCP, so per-port forwarding does not apply.

File injection

You can upload files on the image and give each a destination path inside Windows. Trailer injects them into the disk at build time, so they are present the first time Windows boots.

Destination paths may be written in Windows style or POSIX style. All of these are accepted and treated the same:

C:\Users\Public\Desktop
C:/Users/Public/Desktop
c:\Users\Public\Desktop
/Users/Public/Desktop
\Users\Public\Desktop

Each file lands at <destination>/<filename>, so the destination is treated as a directory.

Volumes

Trailer volumes attached to a Windows workspace show up inside Windows as drives. They are shared over virtio-fs, independent of the workspace network mode.

Drive letters are assigned from Z: downward in attach order: the first attached volume becomes Z:, the second Y:, and so on. Each drive is labeled with the volume’s name. The letter pool runs out after roughly 22 volumes (C: is the system drive, A: and B: are reserved). Past that, the volume is still attached to the VM but gets no drive letter.

Volumes only mount if the image was built against a recent Windows base. If an older image shows no drives, rebuild the image.