[HN Gopher] Claude Code for Infrastructure
___________________________________________________________________
Claude Code for Infrastructure
Author : aspectrr
Score : 95 points
Date : 2026-02-04 18:34 UTC (4 hours ago)
(HTM) web link (www.fluid.sh)
(TXT) w3m dump (www.fluid.sh)
| aspectrr wrote:
| 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!
| redrove wrote:
| 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?
| jondwillis wrote:
| One allows middleman rent-seeking and the other does not so
| much.
| aspectrr wrote:
| 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.
| amanzi wrote:
| 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.
| aspectrr wrote:
| True. Tried to make it simpler but clearly not a good enough
| job!
| nkko wrote:
| 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.
| aspectrr wrote:
| YOOO thanks niko! Currently reworking lots of wording to make
| it easier to understand!
| tayo42 wrote:
| > 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.
| lijok wrote:
| FUCK NO. Who in their right mind would let an LLM connect to
| prod?
| locusofself wrote:
| Maybe at a greenfield startup. Where I work this idea wouldn't
| be entertained for a millisecond.
| jhickok wrote:
| why does it have to connect to prod in order to be useful?
| xyzzy123 wrote:
| 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.
| thenewnewguy wrote:
| Sandpit should be a personal (often local, if possible) dev
| environment. The reason people get mad about dev being broken
| for long periods of time is that they cannot use dev to test
| their changes if your code (that they depend on) is broken in
| dev for long periods of time.
| xyzzy123 wrote:
| Agreed on all points. Local loops are faster and safer
| wherever possible.
|
| But particularly for devops / systems focused work, you
| lose too much "test fidelity" if you're not integrating
| against real services / cloud.
| lijok wrote:
| There's no sandpit, only prod and dev, and you're not allowed
| to break prod. Your developers work in partitions of prod.
| Dev is used for DR and other infra testing.
| qudat wrote:
| I think you would be very surprised at a) how useful it would
| be and b) how lax prod can be depending on the company culture
| and stakes.
| aspectrr wrote:
| 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.
| lijok wrote:
| What's a production cloned sandbox? Take my comment as
| feedback that the landing page is anaemic
| lfx wrote:
| Hey Collin!
|
| 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.
| flowardnut wrote:
| agreed, the repo readme is far more informative than the
| website
| aspectrr wrote:
| 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!
| falloutx wrote:
| 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.
| aabajian wrote:
| That is the problem with software developers with expertise in
| software, but no deep domain knowledge outside the CS world.
| tempest_ wrote:
| It is my belief with some exceptions it is almost always
| easier to teach a domain expert to code than it is to teach a
| software developer the domain.
| bluGill wrote:
| For problems that can be solved with only a small amount of
| simple code that is true. However software can become very
| complex and the larger/more complex the problem is the more
| important software developers are. It quickly becomes
| easier to teach software developers enough of your domain
| than to teach domain experts software.
|
| In a complex project the hard parts about software are
| harder than the hard parts about the domain.
|
| I've seen the type of code electrical engineers write (at
| least as hard a domain as software). They can write code,
| but it isn't good.
| paodealho wrote:
| It is my experience that most of these business domain
| experts snore the moment you talk about anything related to
| the difficulties of creating software.
| vntok wrote:
| Until a few months ago, domain experts who ciuldn't code
| would "make do" with some sort of Microsoft Excel
| Spreadsheet From Hell (MESFH), an unholy beast that would
| usually start small and then always grow up to become a
| shadow ERP (at best) or even the actual ERP (at worst).
|
| The best part, of course, is that this mostly works, most
| of the time, for most busineses.
|
| Now, the same domain experts -who still cannot code- will
| do the exact same thing, but AI will make the
| _spreadsheet_ more stable (actual data modelling), more
| resilient (backup infra), more powerful (connect from /to
| anything), more ergonomic (actual views/UI), and
| generally more easy to iterate upon (constructive yet
| adversarial approach to conflicting change requests).
| bopbopbop7 wrote:
| > AI will make the spreadsheet more stable
|
| Hallucinations sure make spreadsheets nice and stable.
| HolyLampshade wrote:
| Yeah, I think the issue has more to do with the curiosity
| level of the participant rather than whether they are a
| business domain expert or a software engineering expert.
|
| There's a requisite curiosity necessary to cross the
| discomfort boundary into how the sausage is made.
| imiric wrote:
| That doesn't track at all IME.
|
| Programming is not something you can teach to people who
| are not interested in it in the first place. This is why
| campaigns like "Learn to code" are doomed to fail.
|
| Whereas (good) programmers strive to understand the domain
| of whatever problem they're solving. They're comfortable
| with the unknown, and know how to ask the right questions
| and gather requirements. They might not become domain
| _experts_ , but can certainly learn enough to write
| software within that domain.
|
| Generative "AI" tools can now certainly help domain experts
| turn their requirements into software without learning how
| to program, but the tech is not there yet to make them
| entirely self-sufficient.
|
| So we'll continue to need both roles collaborating as they
| always have for quite a while still.
| no_wizard wrote:
| Every single time I try to get a domain expert at $job to
| let me learn more about the domain it goes goes nowhere.
|
| My belief is that engineers should be the prime candidates
| to be learning the domain, because it can positively
| influence product development. There's too many layers
| between engineers and the the domain IME
| isubkhankulov wrote:
| In practice, does that happen? Usually companies try to
| bring the best of both and build from there.
| MattGaiser wrote:
| Pretty much. I'm working on a few things with several people
| and I'm now constrained by their ability to find stuff to
| build.
| ge96 wrote:
| I want to make a business, but what is the business
| CuriouslyC wrote:
| It's way easier to raise for dev tools than domain tools
| right now.
| mindwok wrote:
| Speak for yourself. I've been using Claude Code to build lots
| of customer facing things.
| jrvarela56 wrote:
| I've been a year deep into my first job out of tech. There is a
| never ending slew of problems where being able to code,
| specially now with AI, means you have wizard-like powers to
| help your coworkers.
|
| My codebase is full of one-offs that slowly but surely converge
| towards cohesive/well-defined/reusable capabilities based on
| 'real' needs.
|
| I'm now starting to pitch consulting to a niche to see what
| sticks. If the dynamic from the office holds (as I help them,
| capabilities compound) then I'll eventually find something to
| call 'a product'.
| neochief wrote:
| Can I ask what do you do now?
| nerdsniper wrote:
| I'm really enjoying these LLMs for making ad-hoc tooling / apps
| for myself. Things that I only need for a day or a week, that
| don't need to work perfectly (I can work around bugs).
|
| It's really liberating. Instead of saying "gosh I wish there
| was an app that..." I just make the app and use it and move on.
| mierz00 wrote:
| Talk to people.
|
| There are an infinite amount of problems to solve.
|
| Deciding whether they're worth solving is the hard part.
| closewith wrote:
| There are companies making a lot of money directly from
| software largely written by LLMs especially since Claude Code
| was released, but they aren't mentioning LLMs or AI in any
| marketing, client communications, or public releases. I'm at
| least very aware that we need to be able to retire before LLMs
| swamp or obsolete our niche, and don't want to invite
| competition.
|
| Outside of tech companies, I think this is extremely common.
| Forgeties79 wrote:
| Someone on HN pointed out how all the LLM companies are
| basically going "we made this thing, can y'all please find the
| billion dollar application for it?" and that really made a lot
| of things - namely why I'm frequently raising an eyebrow at
| these tools and the vague promises/demand that we use them -
| click into place.
|
| Don't get me wrong, I have found uses for various AI tools. But
| nothing consistent and daily yet, aside from AI audio repair
| tools and that's not really the same thing.
| aspectrr wrote:
| Sell the shovels!!
| ge96 wrote:
| Side note, been watching gold prospecting channels lately,
| there will be these dig sites/claims people go to, they'll do
| their thing, dig a hole, run it through some angled ramp
| water contraption... they get like nothing, it's the
| experience I suppose. But I was wondering what the owner gets
| from all these people showing up.
|
| They'll work for hours and end up with $4 of gold
| greymalik wrote:
| When there's a gold rush, sell shovels.
| mym1990 wrote:
| I find myself building fun tools for myself and things that
| help with quality of life _slightly_ , but I don't need all
| this extra enterprise stuff for that. I actually find myself
| more likely to use something I built because I am proud of it,
| even if there is already something on the market that addresses
| my need.
| zurtri wrote:
| Another option is to bring your coding skills to a industry not
| particularly known for using tech.
| imiric wrote:
| This type of software is mainly created to gain brand
| recognition, influence, or valuation, not to solve problems for
| humans. Its value is indirect and speculative.
|
| These are the pets.com of the current bubble, and we'll be
| flooded by them before the damn thing finally pops.
| headcanon wrote:
| Maybe have it build some toy apps just for fun! My wife and I
| were talking once about typing speed and challenged each other
| to a typing competition. the existing ones I found weren't very
| good and were riddled with ads, so I had Claude build one for
| us to use.
|
| Or maybe ask yourself what do you like to do outside of work?
| maybe build an app or claude skill to help with that.
|
| If you like to cook, maybe try building a recipe manager for
| yourself. I set up a repo to store all of my recipes in
| cooklang (similar to markdown), and set up claude skills to
| find/create/evaluate new recipes.
|
| Building the toy apps might help you come up with ideas for
| larger things too.
| dubeye wrote:
| building is the easy bit, more than ever.
|
| selling it is the hard part, nothing new there
| cortesoft wrote:
| One of my first professional coding jobs was in 2007 when
| Facebook first introduced 'Facebook Apps'. I worked for a
| startup making a facebook app, and EVERY SINGLE app company had
| the same monetization strategy: Selling ads for other facebook
| apps.
|
| So the lifecycle of an app would be:
|
| 1) Create your game/quiz/whatever app.
|
| 2) Pay a successful app $x per install, and get a bunch of app
| installs.
|
| 3) Put all sorts of scammy "get extra in game perks if you
| refer your friends" to try to become viral.
|
| 4) Hope to become big enough that people start finding you
| without having to pay for ads.
|
| 5) Sell ads to other facebook app startups to generate installs
| for them.
|
| It was a completely circular economy. There was not product or
| income source other than the next layer of the pyramid.
|
| It didn't last long.
| baby wrote:
| I'm on the other hand, I have a million ideas and AI has
| allowed me to implement so many of them.
| baalimago wrote:
| It's pretty cool. What would be cooler is to have it as a MCP
| server... and then use claude code
| hebejebelus wrote:
| 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.
| aspectrr wrote:
| Thanks! Kubernetes is the next infrastructure primitive that I
| want to support but I'm glad you like. If you have any
| questions or ideas, lmk!
| boondongle wrote:
| The real problem is just the volatility for the employees.
| Unless Board of Directors/Owners punish downtime, you risk a
| dark pattern of uptime just being a nice-to-have when I can
| just replace any expertise with the next kid out of college +
| Claude.
|
| So you really need customers to react. And this isn't
| theoretical - people have already lost their jobs and there's
| really, really good people in the market available right now.
| tobi_bsf wrote:
| Whats wrong with just using claude code for infrastructure? Works
| great tbh.
| aspectrr wrote:
| I wish, for my work it would be a safety nightmare. I left a
| comment on this topic.
| https://news.ycombinator.com/reply?id=46889704&goto=item%3Fi...
| ekaesmem wrote:
| Please at least write the README.md by yourself. It's excessively
| lengthy.
| levkk wrote:
| So... I already tell Claude Code to do this. Just run kubectl for
| me please and figure out why my helm chart is broken.
|
| Scary? A little but it's doing great. Not entirely sure why a
| specialized tool is needed when the general purpose CLI is
| working.
| hebejebelus wrote:
| Yeah. The times I have let claude off the read-only leash, it's
| gone fine for me too (with stern warnings not to do anything
| stupid, and a close eye). But that's not really solving the
| same problem as this project, I guess. From what I can see this
| is using a safer and more reproducible method (and not k8s
| native, so it feels a little foreign to me).
| giancarlostoro wrote:
| In Zed I just have it auto approve everything, macOS will
| scream if "Zed" tries to escape the folder its in anyway.
| hivacruz wrote:
| I do the same. I was thinking about creating read-only
| kubeconfigs for him to make sure it can't do bad stuff but with
| a good SKILL.md, it works perfectly.
| levkk wrote:
| Him! That settles the Turing test debate.
| irl_zebra wrote:
| I've noticed a lot of LLM-based tools that are essentially this
| sort of thing. Just a slightly more specific prompt wrapper
| around the core capability that can already do the thing. It's
| so bad.
| aspectrr wrote:
| Lol, that does sounds a little scary but if it works it works.
| Mainly I built this to prevent there being a chance that
| changes affect production. This is meant to be used with scale
| (say hundreds of VMs) vs 1. From a safety perspective running
| Claude Code with just a watchful eye would not fly in my
| environment, which is why I built something like this.
| bakies wrote:
| I let it read-only and gitops driven and find it's really good
| and feels pretty safe to get it to PR fixes. Run it with no
| permission checks
| messh wrote:
| Yeah, I'm telling it to use aws cli to spin up instances,
| configure them, start servers, read cw logs etc.
| esafak wrote:
| An infrastructure tool's primary installation method should NOT
| be curl | sh
| charcircuit wrote:
| It should be. This is the least friction way to do so as server
| Linux operating systems still have not agreed on a common
| application format / package manager.
| esafak wrote:
| > It should be. This is the least friction way to do so as
| server Linux operating systems still have not agreed on a
| common application format / package manager.
|
| Nowhere in your response did you mention security.
| qainsights wrote:
| Can't we just use Claude Code straight up?
| alexandercheema wrote:
| Isn't Claude Code for Infrastructure just...Claude Code?
| aspectrr wrote:
| Hey, thanks for the comment. I answer this question in more
| depth on the website https://fluid.sh or this comment:
| https://news.ycombinator.com/reply?id=46889704&goto=item%3Fi...
|
| This lets AI work on cloned production sandboxes vs running on
| production instances. Yes you can sandbox Claude Code on a
| production box, but it cannot test changes like it would for
| production-breaking changes. Sandboxes give AI this flexibility
| allowing it to safely test changes and reproduce things via IaC
| like Ansible playbooks.
| stackskipton wrote:
| Ops person here.
|
| 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.
| aspectrr wrote:
| Hey no problem! I'll work on the demo more. I discuss this in
| my comment here:
| https://news.ycombinator.com/reply?id=46889704&goto=item%3Fi...
|
| and on the website: https://fluid.sh
|
| But fluid lets AI investigate, explore, run commands, and edit
| files in a production-cloned sandbox. LLMs are great at writing
| IaC, but the LLMs won't get the right context from just
| generating an Ansible Playbook. They need a place to run
| commands safely and test changes before writing the IaC. Much
| like a human, hence the sandbox.
| bigcat12345678 wrote:
| This is the most plausible tool for vibe infra I can think of
| turtlebits wrote:
| Making clones of production isn't trivial. 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.
___________________________________________________________________
(page generated 2026-02-04 23:00 UTC)