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!
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.
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.
> 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.
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
> 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
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.
Many places have "dev", "test" "prod"... but IMHO you need "sandpit" as well.
From an ops point of view as orgs get big enough, dev wraps around to being prod-like... in the sense that it has the property that there's going to be a lot of annoyed people whose time you're wasting if you break things.
You can take the approach of having more guard rails and controls to stop people breaking things but personally I prefer the "sandpit" approach, where you have accounts / environments where anything goes. Like, if anyone is allowed to complain it's broken, it's not sandpit anymore. That makes them an ok place to let agents loose for "whole system" work.
I see tools like this as a sort of alternative / workaround.
Hey, I get it. I don't want LLMs on prod at all. I made this to let agents connect to production cloned sandboxes, not production itself. I hope this helps your concerns, but I understand either way. Lmk with any other questions.
- The website tells less than your comment here. I want to try but have no idea how destructive it can be.
- You need to add / mention how to do things in the RO mode only.
- Always explain destructive actions.
Few weeks ago I had to debug K8S on the GCP GDC metal, Claude Code helped me tons, but... I had to recreate whole cluster next day because agent ran too fast deleted things it should not delete or at least tell me the full impact. So some harness would be nice.
Hey! Yes I updated the website with some more of my comments.
- RO mode would be a good idea
- Agreed on explaining destructive actions. The only (possibly) destructive action is creating the sanbox on the host, but that asks the user's permission if the host doesn't have enough resources. Right now it supports VMs with KVM. It will not let you create a sandbox if the host doesn't have enough ram or cpus.
- The kubernetes example is exactly what this is built for, giving AI access is dangerous but there is always a chance of it messing something. Thanks for the comment!
All these tools to build something, but nothing to build. I feel like I am part of a Pyramid Scheme where every product is about building something else, but nothing reaches the end user.
Note: nothing against fluid.sh, I am struggling to figure out something to build.
Clever solution. I think ops (like this) and observability will be pretty hot markets for a while soon. The code is quite cheap now, but actually running it and keeping it running still requires some amount of background. I've had a number of acquaintances ask me how they can get their vibe coded app available for others to use.
I really like this idea. I do a lot of kubernetes ops with workloads I'm unfamiliar with (and not directly responsible for) and often give claude read access in order to help me debug things, including with things like a grafana skill in order to access the same monitoring tools humans have. It's saved me dozens of hours in the last months - and my job is significantly less frustrating now.
Your method of creating ansible playbooks makes _tons_ of sense for this kind of work. I typically create documentation (with claude) for things after I've worked through them (with claude) but playbooks is a very, very clever move.
I would say something similar but as an auditable, controllable kubernetes operator would be pretty welcome.
I'm already using LLM to generate things and I'm not sure what this adds. The Demo isn't really doing it for me but maybe I'm wrong target for it. (What is running on that server? You don't know. Build your cattle properly!)
Maybe this is better for one man band devs trying to get something running without caring beyond, it's running.
Making clones of production isn't trivial. Is your app server clone going to connect to your production database? It is going to spin up your whole stack? Seems a bit naive.
A better approach is to have AI understand how prod is built and make the changes there instead of having AI inspect it and figure out how to apply one off changes.
First I’m personally never going to create infrastructure in the console. I’m going to use IAC from the get go. That means I can reproduce my infra on another account easily.
Second if I did come across an environment where this was already the case, there are tools for both Terraform and CloudFormation where you can reverse your infra to reproducible IAC.
After that, let Claude go wild in my sandbox account with a reasonably scoped IAM role with temporary credentials
> LLMs are great at generating Terraform, OpenTofu, Ansible, etc. but bad at guessing how production systems work.
Sorry, that last part is absolutely not the case from my experience. IaC also uses the API to inquire about the infrastructure, and there are existing import/export tools around it, so I’m not exactly sure what you are gaining by insisting on abandoning it. IaC also has the benefit of being reusable and commitable.
So this is a client/server thing to control KVM via libvert and provision SSH keys to allow LLM agent access to the VMs?
How does the Ansible export work? Do the agents hack around inside the VM and then write a playbook from memory, or are all changes made via Ansible?
If Ansible playbooks are the artifact, what does features does Fluid offer over just having agents iterate on an Ansible codebase and having Ansible drive provisioning?
I use Pulumi for work, and their AI solution (Pulumi Neo) works amazingly well in troubleshooting cloud issues. It's informed of the cloud state and recent changes right from their platform, which is pretty amazing. Compared to using Azure CoPilot for the same purposes, Pulumi Neo was faster in generating responses, and these responses were actionable and solved my issues. CoPilot was laughably useless comparably.
55 comments
[ 2.7 ms ] story [ 56.4 ms ] threadWhat 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!
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.
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
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.
From an ops point of view as orgs get big enough, dev wraps around to being prod-like... in the sense that it has the property that there's going to be a lot of annoyed people whose time you're wasting if you break things.
You can take the approach of having more guard rails and controls to stop people breaking things but personally I prefer the "sandpit" approach, where you have accounts / environments where anything goes. Like, if anyone is allowed to complain it's broken, it's not sandpit anymore. That makes them an ok place to let agents loose for "whole system" work.
I see tools like this as a sort of alternative / workaround.
Interesting idea, few things:
- The website tells less than your comment here. I want to try but have no idea how destructive it can be.
- You need to add / mention how to do things in the RO mode only.
- Always explain destructive actions.
Few weeks ago I had to debug K8S on the GCP GDC metal, Claude Code helped me tons, but... I had to recreate whole cluster next day because agent ran too fast deleted things it should not delete or at least tell me the full impact. So some harness would be nice.
- The kubernetes example is exactly what this is built for, giving AI access is dangerous but there is always a chance of it messing something. Thanks for the comment!
Note: nothing against fluid.sh, I am struggling to figure out something to build.
I really like this idea. I do a lot of kubernetes ops with workloads I'm unfamiliar with (and not directly responsible for) and often give claude read access in order to help me debug things, including with things like a grafana skill in order to access the same monitoring tools humans have. It's saved me dozens of hours in the last months - and my job is significantly less frustrating now.
Your method of creating ansible playbooks makes _tons_ of sense for this kind of work. I typically create documentation (with claude) for things after I've worked through them (with claude) but playbooks is a very, very clever move.
I would say something similar but as an auditable, controllable kubernetes operator would be pretty welcome.
Scary? A little but it's doing great. Not entirely sure why a specialized tool is needed when the general purpose CLI is working.
I'm already using LLM to generate things and I'm not sure what this adds. The Demo isn't really doing it for me but maybe I'm wrong target for it. (What is running on that server? You don't know. Build your cattle properly!)
Maybe this is better for one man band devs trying to get something running without caring beyond, it's running.
A better approach is to have AI understand how prod is built and make the changes there instead of having AI inspect it and figure out how to apply one off changes.
Models are already very good at writing IaaC.
First I’m personally never going to create infrastructure in the console. I’m going to use IAC from the get go. That means I can reproduce my infra on another account easily.
Second if I did come across an environment where this was already the case, there are tools for both Terraform and CloudFormation where you can reverse your infra to reproducible IAC.
After that, let Claude go wild in my sandbox account with a reasonably scoped IAM role with temporary credentials
Sorry, that last part is absolutely not the case from my experience. IaC also uses the API to inquire about the infrastructure, and there are existing import/export tools around it, so I’m not exactly sure what you are gaining by insisting on abandoning it. IaC also has the benefit of being reusable and commitable.
How does the Ansible export work? Do the agents hack around inside the VM and then write a playbook from memory, or are all changes made via Ansible?
If Ansible playbooks are the artifact, what does features does Fluid offer over just having agents iterate on an Ansible codebase and having Ansible drive provisioning?
Next month - 'Sorry I caused a $200,000 bill...'
"install kimi 2.5 on a 4x mi300x vm and connect the endpoint to opencode, shut it down in 4 hours"
We're getting close.