My name is Collin, I've been working on automating my job and open-sourcing the results. I work as an ELK engineer and don't like so i started building this on my own time to find out if this was something that could be handled by agents and found success! The coolest part of which is built with sandboxes that have data stubs (kafka, s3, api) so the agent can model data pipelines in a full feedback loop without touching a cluster. Because of this I am working on an Elasticsearch consultancy comprised of me and a swarm of these agents working to build client projects.
In the land of infrastructure, servers are sacred. Humans are barely allowed to SSH into these servers, and LLMs are not even in the picture.
This is for good reason, one misspelled command and production is down. This is the reality that I saw working in infrastructure. However, I believe that the jump that Claude Code gave software engineers will happen to sys-admins, platform engineers, and dev ops people alike. I wanted to let LLMs onto these servers, and let them do my boring debugging work, safely. So that's what I built with Fluid.
A safe, auditable way to let LLMs debug and manage Linux Servers. Redact secrets, IP addresses, and keys from LLM inputs, have custom allowlists without completely hindering the LLMs performance, and audit logs. And once you are ready, give the LLMs sandboxes of your Linux Servers, allowing them to fix issues all on their own, safely.
In the land of infrastructure, servers are sacred. Humans are barely allowed to ssh into these servers, and LLMs are not even in the picture.
This is for good reason, one misspelled command and production is down. This is the reality that I saw working in infrastructure. However, I believe that the jump that Claude Code gave software engineers will happen to sys-admins, platform engineers, and dev ops people alike. I wanted to let LLMs onto these servers, and let them do my boring debugging work, safely. So that's what I built with Fluid.
A safe, auditable way to let LLMs debug and manage Linux Servers. Redact secrets, IP addresses, and keys from LLM inputs, have custom allowlists without completely hindering the LLMs performance, and audit logs. And once you are ready, give the LLMs sandboxes of your Linux Servers, allowing them to fix issues all on their own, safely.
Yo, fluid is built with on-prem in mind, specifically VMs. This is my initial use case for it. I am currently working on a remote version of fluid, where instead of CLI tool, it would be more of a codex/claude code app with a UI where you can install a server and then command hundreds of agents at once to work on infrastructure. Is this what you had in mind?
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.
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!
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.
My name is Collin, I've been working on automating my job and open-sourcing the results. I work as an ELK engineer and don't like so i started building this on my own time to find out if this was something that could be handled by agents and found success! The coolest part of which is built with sandboxes that have data stubs (kafka, s3, api) so the agent can model data pipelines in a full feedback loop without touching a cluster. Because of this I am working on an Elasticsearch consultancy comprised of me and a swarm of these agents working to build client projects.
Let me know if you have any questions!
reply