Hey HN,

My name is Collin and I built fluid.sh because I wanted AI agents to work on my infrastructure safely and give the boost that Claude Code has given to me, to fellow Infra engineers.

I built this as I work with infrastructure a ton in an enterprise incumbent and wanted to let agents work on our infrastructure rather than suggest stuff.

The problem: We can give AI agents root access to codebases, but not to servers. One bad command on production and you're getting paged at 3 AM. So we limit agents while humans do the actual execution. We don't get the same feedback loops software engineers do.

The solution: Give the agent root access to an isolated VM instead. Let it work autonomously—provision servers, configure firewalls, set up services, deploy applications. Then diff the changes, review what it did, and approve an Ansible playbook to apply to production.

How it works: 1. Clone a golden VM image into an isolated KVM sandbox 2. Agent gets full root access and works autonomously 3. Snapshots checkpoint progress (rollback if needed) 4. Diff snapshots to see exactly what changed 5. Auto-generate Ansible playbook from the agent 6. Human reviews and approves (blocking workflow) 7. Playbook applies to production

Tech stack: Go + libvirt/KVM, React, Python SDK, PostgreSQL

Use cases: - Autonomous server provisioning and configuration - Self-healing infrastructure (agent diagnoses and fixes issues) - Migration automation (agent figures out the steps) - Compliance remediation - On-call automation (agent triages and resolves alerts)

Why VMs instead of containers? - Full OS isolation (not namespace isolation) - Real networking stack for firewall/routing work - Snapshot/restore is native to the hypervisor - Agents can reboot, modify kernel params, install kernel modules - Closer to production reality

GitHub: https://github.com/aspectrr/fluid.sh Demo video: https://youtu.be/nAlqRMhZxP0

Happy to answer questions or feedback!

Show HN: Fluid.sh – Make Infrastructure Safe for AI