Eventually it got to a point it could iterate very quickly and was really only constrained by total system RAM which meant a dozen at most copies could be running simultaneously.
All those actions within my homelab are automated via Ansible and bash scripts (I only run Linux), I am only notified if something goes wrong like a backup failed.
I get it if you never worked in IT, that is fine, but you need zero AI to get the above fully automated.
Does Claude keep versioning of the changes?? I host my own repos via Forgejo, Ansible and the automation process consume the config files from there, one source of truth. If my whole setup burns with fire, I can bring everything back online from the offsite Ansible playbook located at Codeberg.
There are so many unknowns and the ability for the agents to dynamically adjust and make decisions allows for some really powerful autonomous workflows.
https://learn.microsoft.com/en-us/windows-hardware/manufactu...
https://learn.microsoft.com/en-us/windows-hardware/manufactu...
I don't use windows but have to run windows 11 VM to access special devices. I don't want to bother with licenses, although I have them, and creating a new incus QEMU VM from scratch everytime from an ISO takes ~5m, freeing me up from worrying about all the activation and license drama.
If the activation and license setup was easy/automated in QEMU, I would imagine snapshots would be way easier. I would prefer not needing to connect to the internet.
Your info might be like decades out of date, since windows 10 it's just been an overlay and locking out some appearance customizations (you can still set them via other means though).
This post covers how we added Windows to a test infrastructure built around Linux runners. The central problem was giving each test a clean, logged-in Windows desktop without waiting 2–3 minutes for a VM to boot.
We extended the device scheduler we already use for mobile testing. It maintains warm pools of Windows VMs on GCE. Each test claims a ready VM, uses it once, and releases it. The VM is then destroyed and replaced, rather than cleaned up for the next test.
The test code stays in a Linux pod. Playwright connects to browsers on the Windows machine over CDP, while WebdriverIO and Appium handle native apps through WinAppDriver. A small Go agent captures the desktop with FFmpeg and streams it over WebRTC for live viewing and recordings.
That separation lets a single test move between a browser and a native Windows app without requiring a separate Windows runner pipeline.
The trade-off is that we keep idle Windows VMs ready and install the app under test on every run. In exchange, tests don’t inherit another run’s files, registry changes, or saved sessions.
I’d love to answer any questions!