Fluid - Claude Code para infraestructura

 (fluid.sh)
5 puntos por GN⁺ 2026-02-06 | 1 comentarios | Compartir por WhatsApp
  • Herramienta basada en terminal que crea un entorno sandbox replicado para que los agentes de IA puedan trabajar con infraestructura real de forma segura
  • Ejecuta comandos, modifica archivos y prueba conexiones en una VM replicada o en un clúster de Kubernetes, y genera automáticamente el resultado en forma de Ansible Playbook
  • A diferencia del enfoque en el que un LLM solo genera código, replica el entorno real para producir IaC (Infra-as-Code) probado y validado
  • Usa certificados SSH efímeros para ejecutar comandos de forma segura, y requiere aprobación humana cuando hay acceso a internet o en hosts con recursos limitados
  • Todas las órdenes y cambios quedan registrados en un log de auditoría, y permite a los desarrolladores experimentar con infraestructura en local y crear configuraciones reproducibles

Resumen de Fluid

  • Fluid es un agente de terminal que permite a la IA trabajar en un sandbox que replica infraestructura de producción (por ejemplo, VM o clústeres K8s)
    • El agente de IA puede ejecutar comandos, probar conexiones y editar archivos
    • Después, convierte los resultados en un Ansible Playbook que puede aplicarse al entorno de producción
  • Este enfoque permite que la IA no tenga que adivinar la estructura real del sistema, sino que pueda experimentar directamente en el entorno replicado

Diferencias frente a la generación tradicional de IaC basada en LLM

  • Los LLM generan bien código para Terraform, OpenTofu, Ansible y otras herramientas, pero no logran comprender con precisión el comportamiento del entorno real de producción
  • Fluid accede a infraestructura replicada para ejecutar comandos y realizar pruebas primero, y luego redacta la IaC con base en esos resultados
  • Este enfoque permite validación y experimentación antes del despliegue

Diferencias con Claude Code y diseño de seguridad

  • Fluid está diseñado para que Claude Code no se conecte por SSH directamente a servidores de producción desde el entorno local
  • Todo el trabajo se ejecuta únicamente dentro del sandbox, y Fluid lo administra
  • Usa certificados SSH efímeros y muestra en tiempo real los resultados de la ejecución de comandos
  • En hosts con poca memoria o CPU, acceso a internet, instalación de paquetes y similares, se requiere aprobación humana

Funciones principales

  • Sandbox Isolation: replica una VM al instante para probar cambios sin afectar producción
  • Context-Aware: explora el SO, los paquetes y las herramientas CLI del host para actuar según el entorno
  • Full Audit Trail: registra todos los comandos y cambios para permitir auditoría y revisión
  • Generación automática de Ansible Playbook: crea código de infraestructura reproducible con base en lo realizado en el sandbox

Ejemplo de uso

  • Fluid crea un sandbox con el comando v create_sandbox y muestra la IP y el estado
  • Con v run_command ejecuta órdenes; en el ejemplo, instala y ejecuta Apache HTTP Server en un entorno Ubuntu 22.04
  • Verifica el funcionamiento del servidor web con curl localhost
  • Después, con v create_playbook genera el playbook httpd-setup
    • Incluye 4 tareas: actualizar la caché de apt, instalar Apache, crear index.html e iniciar y habilitar el servicio Apache
  • El playbook generado permite reproducir la misma configuración en otros servidores Ubuntu

Instalación y ejecución

  • Se instala en la estación de trabajo local como un agente de terminal
  • Tras la instalación, es posible crear sandboxes y hacer pruebas directamente desde el entorno local

Resumen

  • Fluid es una herramienta que combina automatización de infraestructura basada en IA y aislamiento seguro
  • Con ejecución de comandos en tiempo real, trazabilidad de auditoría y generación de código Ansible, facilita una gestión de infraestructura segura y reproducible
  • Es una versión de infraestructura de Claude Code, y ofrece un nuevo enfoque para que desarrolladores y operadores experimenten imitando entornos de producción

Lecturas relacionadas

1 comentarios

 
GN⁺ 2026-02-06
Comentarios en Hacker News

  • Últimamente sobran las herramientas para construir cosas, pero da la sensación de que no hay nada que construir. Se siente como si todos los productos fueran parte de una estructura piramidal para otra herramienta de build. No es una queja sobre fluid.sh, simplemente yo también estoy pensando qué debería construir.

    • Trabajé en una startup durante el boom de las apps de Facebook en 2007, y todas las empresas de apps vendían anuncios de otras apps. El ecosistema de apps funcionaba como una economía completamente circular, sin valor real para el usuario ni fuentes de ingresos genuinas. Al final no duró mucho.
    • El problema es que muchos desarrolladores profundizan mucho en la tecnología de software sin conocimiento del dominio.
    • Yo también llevo un año trabajando en una industria no tecnológica, y gracias a mi capacidad de programar mis colegas me tratan como si fuera mago. Resolviendo problemas reales, el codebase se ha ido convirtiendo poco a poco en funcionalidades reutilizables. Ahora estoy intentando hacer consultoría con base en esta experiencia, y creo que algún día encontraré algo que pueda llamar “producto”.
    • Desde una perspectiva macroeconómica, hay un punto en el que si la tecnología avanza demasiado rápido, la producción disminuye. El boom actual de herramientas de IA parece un fenómeno parecido. Con cambios tan rápidos, todos estamos aprendiendo otra vez. Al final, estamos construyendo sobre arena movediza.
    • Yo también tuve esa misma duda, pero últimamente empecé a usar estas herramientas para ingeniería inversa. Por ejemplo, no me gustaba la calidad de impresión en Linux de una impresora de etiquetas china, así que hice un script en Go para imprimir directamente por BLE. En vez de descompilar la app de Android, se lo dejé a una IA agéntica, y ahora incluso tengo una versión para navegador y otra para ESP32. Lo resumí en Making a label printer work under Linux using Agentic AI.

  • La razón por la que me reí al ver el comando curl -fsSL https://fluid.sh/install.sh | bash fue la ironía de que, aunque la intención original era bloquear el acceso SSH por seguridad, al final te hace ejecutar un script de instalación todavía más riesgoso. El tuit relacionado se puede ver aquí.

    • Vivimos en una época en la que le echan veneno a internet para que los LLM recomienden URLs maliciosas. Qué tiempos tan increíbles.

  • Soy Collin y estoy creando fluid.sh. Podrías verlo como una versión de infraestructura de Claude Code. Fluid crea réplicas sandbox de infraestructura de producción (VM, K8s, etc.) para que los agentes de IA ejecuten comandos, modifiquen archivos y hagan pruebas, y luego generen IaC como Ansible Playbooks. La clave es permitir que el LLM explore el entorno real y entienda el contexto, en lugar de solo generar Terraform a ciegas. Por razones de seguridad, está diseñado para que Claude Code no se conecte por SSH directamente a producción, y usa certificados SSH efímeros para que la ejecución de comandos sea trazable. Cuando se trata de hosts con pocos recursos o acceso a redes externas, requiere aprobación humana. ¡Agradezco cualquier feedback!

    • Me pregunto por qué esa explicación no está en la página principal. Ahora mismo el sitio solo dice algo como “Claude Code for infrastructure”, así que para un ingeniero de infraestructura es demasiado poco claro como para instalarlo con una línea de bash.
    • Levantar varias réplicas de la infraestructura para que los agentes se muevan entre ellas parece un desperdicio de costos. Desde el punto de vista de DevOps, esto es ineficiente.
    • Hacer configuración manual en un sandbox remoto no encaja con la filosofía de Infrastructure as Code. Yo ya automatizo suficiente con una combinación de Pulumi, Tilt y Kubernetes. Claude también funciona bien en ese entorno. No hace falta tocar nada directamente por SSH.
    • Entonces no entiendo en qué se diferencia de desplegar Claude Code en una VM existente y ejecutarlo ahí. Ya hay varios métodos de sandboxing. Me da curiosidad cuál es la diferencia real.
    • También se puede replicar infraestructura existente con Terraformer, así que si ni siquiera tienen automatización básica de IaC, el problema es del equipo de DevOps.
    • Yo ya hago cosas como “hacer que Claude Code ejecute comandos kubectl para corregir charts de Helm”. Con un CLI normal funciona perfectamente bien.
      • Muchas de las herramientas basadas en LLM de hoy están en este nivel de wrapper de prompts. No hay una diferenciación esencial.
      • A mí también me da esa impresión, pero este proyecto parece buscar seguridad en entornos a gran escala. Cuando operas cientos de VM, la simple supervisión no alcanza.
      • Yo también ejecuto Claude con una cuenta de solo lectura, y se integra bien con Terraform y AWS CLI. No siento que necesite una herramienta nueva.
      • Yo también lo limito con un kubeconfig de solo lectura, y si escribes bien SKILL.md, funciona con suficiente seguridad.
      • Incluso dejándolo en solo lectura no hubo grandes problemas. Aun así, este proyecto parece enfatizar más la reproducibilidad y la seguridad.
    • Replicar producción no es sencillo. Conexiones a DB o copiar todo el stack completo es algo difícil en la práctica. Más bien creo que sería mejor que la IA entienda la estructura de producción y haga cambios directamente. Los modelos ya son bastante capaces de escribir IaC.
    • La idea es interesante. Últimamente el área de operaciones y observabilidad (Observability) está ganando fuerza. Yo también le doy a Claude acceso a Grafana mientras opero Kubernetes para ayudar con debugging, y gracias a eso he ahorrado decenas de horas. El enfoque de generar Ansible Playbooks automáticamente también es excelente desde el punto de vista de la trazabilidad de auditoría.
      • Pero si este tipo de automatización se expande, la inestabilidad laboral del personal de operaciones podría aumentar. De hecho, ya están apareciendo casos de ingenieros experimentados que pierden su trabajo.
      • Me entusiasma saber que hay planes para soporte de Kubernetes. Me gusta la idea.
    • Sinceramente, creo que esto ya es un problema resuelto. La mayoría configura su infraestructura con IaC desde el principio y, si hace falta, puede reconstruirla al revés. Basta con ejecutar Claude en una cuenta sandbox con un rol de IAM.
    • No estoy de acuerdo con la afirmación de que “el LLM no puede inferir bien un sistema de producción”. IaC puede consultar la infraestructura mediante APIs, y sus ventajas son la reutilización y el control de versiones.
      • Estoy de acuerdo en que los entornos DevOps varían entre empresas y que son difíciles de generalizar. La mayoría de las startups todavía sigue batallando al nivel de HCL o YAML.
    • La frase “para hacerlo de forma segura, ejecuta este script con curl” se siente irónica.
    • ¿Esto funciona controlando KVM con libvirt y emitiendo claves SSH para que el LLM acceda a las VM? Me pregunto si los Ansible Playbooks se generan a partir de los cambios dentro de las VM, o si todo se manipula solo con Ansible. Quisiera saber qué funcionalidad diferenciadora tiene frente a simplemente ejecutar Ansible repetidamente.