Overview
Hermes Agent doesn’t have first-class Windows support the way it does on macOS and Linux — that’s generally understood in the community. But if your daily driver is Windows, you’re not locked out. The official docs list several installation paths, each with different trade-offs in resource usage, stability, and workflow fit. The right choice depends on what you’re doing: day-to-day plugin development, 24/7 headless operation, or planning a future move to a cloud server.
Four proven options exist today: WSL2, Docker, a full VM (Hyper‑V / VMware), and the native Windows PowerShell script.
WSL2: The Official Recommendation, Most Complete Experience
WSL2 is essentially a lightweight Linux VM built into Windows, backed by Hyper‑V virtualization. The official Hermes docs list it as the primary option for a straightforward reason — it provides a complete Linux kernel environment where every Hermes feature works without the PTY and shell compatibility issues that plague native Windows setups.
What works well. The Web UI’s embedded terminal only functions correctly under WSL2. Memory overhead sits around 300 MB at idle and auto-releases to Windows when not in use. Startup is near-instant. Bash scripts, cron jobs, subprocess long‑lived connections, MCP servers, custom Python STT plugins — everything behaves exactly like a standard Linux environment.
What to watch out for. Three pain points stand out. First, auto-sleep: WSL2 shuts down idle instances, killing Hermes background processes. You need a keep‑alive script. Second, cross‑filesystem I/O: reading/writing Windows files through /mnt/c/ is noticeably slow. The docs explicitly state that project files must live inside the WSL /home/ filesystem. Third, networking: WSL2 can’t reach the Windows host’s 127.0.0.1 directly — you’ll need port forwarding or the host gateway IP.
There’s also a security angle that’s easy to overlook. WSL2 automatically mounts your C: drive to /mnt/c, meaning rm -rf /mnt/c/Windows is a valid command inside the instance. With an autonomous AI agent this risk multiplies. The fix is simple: keep everything in /home/ and never work under /mnt/c/.
Docker: Lightweight, Stable, Portable
A Docker container is a standard Linux isolation environment running on the host kernel — identical to what you’d get on a bare‑metal server or cloud instance. On Windows, Docker itself depends on the WSL2 kernel, but it adds container orchestration on top of the raw WSL2 experience.
The big improvement over plain WSL2 is no auto‑sleep. Containers stay resident in the background, naturally supporting 24/7 operation without keep‑alive scripts. Resources are allocated on demand: you can cap CPU, memory, and disk I/O per container, avoiding the fixed memory waste of a full VM. Environment dependencies are baked into the image — the same configuration and container can migrate to a cloud server or NAS with minimal friction.
Details to get right. You must start the container with --tty --interactive or PTY interaction breaks. Configuration, plugin, and log directories need persistent volume mounts so data survives container rebuilds. Map all ports: the main service port, Web UI, and any plugin communication ports.
Docker is the best fit for long‑running setups, plugin development, and anyone planning to eventually move to the cloud. If your workflow involves switching between multiple projects, containerized isolation saves you from dependency‑hell. Managing everything with Docker Compose means scaling up or migrating is a single command.
Native Windows (PowerShell): Quick Taste
Hermes ships an official Windows-native install script — one command, no WSL, no Docker, no VM. The upside is minimal: zero environment setup. The downside is that PowerShell’s PTY support lags behind Linux shells, the Web UI embedded terminal won’t work, and some low‑level features may be unstable. It’s under active development and fine for a quick look at Hermes basics, but not suitable as a primary development environment.
Virtual Machine: Complete Isolation, Maximum Stability
Hyper‑V or VMware is the most traditional and reliable approach. Install a full Ubuntu inside the VM, completely isolated from Windows. Snapshots let you roll back any configuration change. With bridged networking, other devices on the LAN can reach Hermes directly without port forwarding — useful if you want to access the agent from a tablet or second machine.
The trade‑offs are clear: high resource overhead (whatever RAM you allocate is permanently consumed), slow startup (30–60 seconds to boot), and cumbersome file sharing — NTFS read/write through shared folders performs poorly. Also, if you have both WSL2 and an older VMware version enabled, you’ll hit Hyper‑V conflicts. VMware 17+ supports a compatibility mode that avoids this.
The VM path makes sense if you need 24/7 uptime without any sleep risk, require PCIe passthrough or CUDA acceleration, or want the strongest possible environment isolation.
Comparison
| Approach | Background Stability | Resource Footprint | Feature Completeness | Portability |
|---|---|---|---|---|
| WSL2 | Idle sleep | Low | Full | Windows only |
| Docker | Always‑resident | Very low | Full | Best |
| VM | Never sleeps | High | Full | Portable but heavy |
| PowerShell | Unstable | Low | Partial | Not portable |
Of the four, Docker achieves the best balance between stability and resource efficiency. WSL2 offers the most complete feature set but needs a sleep workaround. The VM is the most stable but also the heaviest. Choose based on what matters most in your actual workflow.
Which One Should You Pick?
- Day‑to‑day debugging and fast iteration → WSL2. Best feature coverage, most complete experience.
- Long‑running operation, plugin development, future cloud migration → Docker. It inherits WSL2’s lightness and the VM’s stability, with the lowest migration cost.
- Hardware passthrough, CUDA, or extreme isolation → VMware or Hyper‑V. Trade resources for reliability.
- Just want to see what Hermes looks like → PowerShell. One command, zero setup overhead.
Common Pitfalls
- Old VMware and WSL2 can’t coexist — you’ll hit Hyper‑V conflicts. Upgrade to VMware 17+ for compatibility mode.
- Docker containers: don’t skip
--tty --interactive— PTY will break without it. - WSL2 safety: keep code in
/home/, stay out of/mnt/c/. Runwsl --updateto keep the kernel current. - Regardless of approach, manage the Hermes process with systemd inside the Linux environment.
There’s no perfect option. Pick one that fits your constraints and start running — you can always switch later.