zlacker

Hey HN, My name is Collin and I'm working on fluid.sh (https://fluid.sh) the Claude Code for Infrastructure.

What does that mean?

Fluid is a terminal agent that do work on production infrastructure like VMs/K8s cluster/etc. by making sandbox clones of the infrastructure for AI agents to work on, allowing the agents to run commands, test connections, edit files, and then generate Infra-as-code like an Ansible Playbook to be applied on production.

Why not just use an LLM to generate IaC?

LLMs are great at generating Terraform, OpenTofu, Ansible, etc. but bad at guessing how production systems work. By giving access to a clone of the infrastructure, agents can explore, run commands, test things before writing the IaC, giving them better context and a place to test ideas and changes before deploying.

I got the idea after seeing how much Claude Code has helped me work on code, I thought "I wish there was something like that for infrastructure", and here we are.

Why not just provide tools, skills, MCP server to Claude Code?

Mainly safety. I didn't want CC to SSH into a prod machine from where it is running locally (real problem!). I wanted to lock down the tools it can run to be only on sandboxes while also giving it autonomy to create sandboxes and not have access to anything else.

Fluid gives access to a live output of commands run (it's pretty cool) and does this by ephemeral SSH Certificates. Fluid gives tools for creating IaC and requires human approval for creating sandboxes on hosts with low memory/CPU and for accessing the internet or installing packages.

I greatly appreciate any feedback or thoughts you have, and I hope you get the chance to try out Fluid!

>>aspect+(OP)
So how is this different from deploying claude code on a VM and letting it run? You can sandbox it in any of the dozen ways already available.

What’s the differentiator?

>>redrov+cg
One allows middleman rent-seeking and the other does not so much.

>>aspect+(OP)
Why would you not put a description like this on your actual website? Your homepage does not explain anything about what this actually does. Are you really expecting infrastructure engineers to install your app with a bash command after only providing the following information?

    Claude Code for infrastructure. Debug, act, and audit everything Fluid does on your infrastructure.

    Create sandboxes from VMs, investigate, plan, execute, generate Ansible playbooks, and audit everything.

>>amanzi+Xq
True. Tried to make it simpler but clearly not a good enough job!

>>redrov+cg
This allows the agent to make any changes in a production clone vs agents running on a production VM. For example, you wouldn't want claude editing crucial config on the chance it brings everything down vs letting it do in a cloned environment where it can test whatever.

>>aspect+(OP)
This is exciting. But I had to read and check everything twice to figure it out, as some already commented. Strong Feedback loop is an ultimate unlock for AI agents and having twins is exactly the right approach.

>>nkko+ZK
YOOO thanks niko! Currently reworking lots of wording to make it easier to understand!

>>aspect+(OP)
> I didn't want CC to SSH into a prod machine from where it is running locally (real problem!). I wanted to lock down the tools it can run to be only on sandboxes while also giving it autonomy to create sandboxes and not have access to anything else.

This is already the modern way to run infra. If your running simple apps, why are you even spinning up vms? Container running platforms make this so easy.

>>aspect+(OP)
And how is this different than just pointing Terraformer at your existing infrastructure and rebuilding it in another account? That is assuming your company is standing complicated infra up by hand and if they are, your entire “DevOps” team or who ever is responsible needs to be fired

>>aspect+(OP)
> By giving access to a clone of the infrastructure, agents can explore, run commands, test things before writing the IaC, giving them better context and a place to test ideas and changes before deploying.

And you thought the costs for burning tokens was high... let's amp it up by spinning up a bunch of cloud infra and let the agents fumble about.

DevOps is my gig, I use agents extensively, I would never do this. This is so wasteful

>>aspect+(OP)
You might want to remove that `.DS_Store` from the root of the repo and add `.DS_Store` to your global git ignore.

>>aspect+ey
It reads like a blog post, not a landing page

>>aspect+(OP)
An agent that runs things in remote sandboxes to set things up doesn’t really fit with Infrastructure as Code.

Lately I have been setting up Pulumi stacks in ephemeral AWS accounts managed by AWS Organizations and working on a Kubernetes cluster locally with Tilt. So far, Claude is pretty good with those things. It seems to have pretty good knowledge of Pulumi, basic knowledge of Tilt, and good knowledge of Kubernetes. It’s a little out of date on some things and needs reminding to RTFM, but it can get a lot done by itself. If it were a real point of friction, a cheat sheet (sorry, “skill”) would be enough to solve the majority of issues.

The example you provide seems to be more along the lines of SSHing into remote boxes and setting things up manually. That’s not really helpful when you want to work on repeatable infra. You try to distinguish yourself from generating Terraform etc., but actually that’s what’s valuable in my experience.