Fluid - Claude Code para infraestrutura

• Ferramenta baseada em terminal que cria um ambiente sandbox clonado para que agentes de IA possam lidar com infraestrutura real com segurança
• Executa comandos, modifica arquivos e testa conexões em VMs clonadas ou em um cluster Kubernetes, gerando automaticamente o resultado no formato de Ansible Playbook
• Em vez de simplesmente usar um LLM para gerar código, clona o ambiente real para criar IaC (Infraestrutura como Código) testada e validada
• Usa certificados SSH efêmeros para executar comandos com segurança, e exige aprovação humana ao acessar a internet ou ao operar em hosts com poucos recursos
• Todos os comandos e alterações são rastreados em logs de auditoria, tornando a ferramenta útil para desenvolvedores experimentarem infraestrutura localmente e criarem configurações reproduzíveis

---

Visão geral do Fluid

• O Fluid é um agente de terminal que permite à IA trabalhar em um sandbox que clona a infraestrutura de produção (ex.: VM, cluster K8s)
  • O agente de IA executa comandos, testa conexões e edita arquivos
  • Depois, converte o resultado em um Ansible Playbook que pode ser aplicado ao ambiente de produção
• Essa abordagem permite que a IA experimente diretamente no ambiente clonado, em vez de tentar adivinhar a estrutura real do sistema

Diferença em relação à geração de IaC baseada em LLM

• LLMs conseguem gerar bem código em Terraform, OpenTofu e Ansible, mas não compreendem com precisão o comportamento do ambiente real de produção
• O Fluid acessa a infraestrutura clonada para executar comandos e testes primeiro, e então escreve a IaC com base nesses resultados
• Essa abordagem viabiliza validação e experimentação antes do deploy

Diferenças em relação ao Claude Code e arquitetura de segurança

• O Fluid foi projetado para que o Claude Code não acesse diretamente os servidores de produção via SSH a partir do ambiente local
• Todo o trabalho é executado apenas dentro do sandbox, sob gerenciamento do Fluid
• Usa certificados SSH efêmeros e exibe em tempo real o resultado da execução dos comandos
• Hosts com pouca memória ou CPU, acesso à internet e instalação de pacotes exigem aprovação humana

Principais recursos

• Sandbox Isolation: clona VMs instantaneamente para testar mudanças sem impactar a produção
• Context-Aware: explora o SO, os pacotes e as ferramentas de CLI do host para agir de acordo com o ambiente
• Full Audit Trail: registra todos os comandos e alterações para auditoria e revisão
• Geração automática de Ansible Playbook: cria código de infraestrutura reproduzível com base no que foi feito no sandbox

Exemplo de uso

• O Fluid cria um sandbox com o comando v create_sandbox, exibindo IP e status
• Com v run_command, executa comandos; no exemplo, em um ambiente Ubuntu 22.04, faz a instalação e execução do Apache HTTP Server
• Usa curl localhost para verificar o funcionamento do servidor web
• Depois, com v create_playbook, gera o playbook httpd-setup
  • Inclui 4 tarefas: atualizar o cache do apt, instalar o Apache, criar o index.html e iniciar/habilitar o serviço do Apache
• O playbook gerado permite reproduzir a mesma configuração em outros servidores Ubuntu

Instalação e execução

• Funciona como um agente de terminal instalado na workstation local
  • Comando de instalação:

    curl -fsSL https://fluid.sh/install.sh | bash  
    fluid  
    

• Após a instalação, é possível criar sandboxes e testar diretamente no ambiente local

Resumo

• O Fluid é uma ferramenta que combina automação de infraestrutura com IA e isolamento de segurança
• Com execução de comandos em tempo real, trilha de auditoria e geração de código Ansible, oferece suporte a um gerenciamento de infraestrutura seguro e reproduzível
• Como uma versão do Claude Code para infraestrutura, propõe uma nova abordagem para que desenvolvedores e equipes de operações experimentem em ambientes que imitam a produção

[GN⁺]

Comentários do Hacker News

• Hoje em dia tem ferramenta de sobra para criar coisas, mas dá a sensação de que falta o que realmente criar
  Parece que todo produto faz parte de uma estrutura em pirâmide para mais uma ferramenta de build
  Não é uma reclamação sobre o fluid.sh, só estou tentando descobrir o que eu mesmo deveria construir

  • Trabalhei numa startup durante o boom dos apps do Facebook em 2007, e toda empresa de app vivia de vender anúncios de outros apps
    O ecossistema de apps virou completamente uma economia circular, sem valor real para o usuário nem fonte de receita de verdade. No fim, não durou muito
  • O problema é que muitos desenvolvedores se aprofundam em software sem ter conhecimento de domínio
  • Eu também estou há um ano trabalhando num setor não técnico, e minhas habilidades de programação fazem os colegas me tratarem como um mago
    Resolvo problemas reais, e a base de código vai evoluindo aos poucos para funcionalidades reutilizáveis
    Agora estou tentando fazer consultoria com base nessa experiência, e acho que um dia vou encontrar algo que possa chamar de "produto"
  • Do ponto de vista macroeconômico, existe uma faixa em que, se a tecnologia avança rápido demais, a produção cai
    O boom atual das ferramentas de IA parece algo parecido. Com mudanças rápidas demais, todo mundo está reaprendendo tudo
    No fim, estamos construindo em areia movediça
  • Eu tive a mesma dúvida, mas recentemente comecei a usar essas ferramentas para engenharia reversa
    Por exemplo, eu não gostava da qualidade de impressão no Linux de uma impressora de etiquetas chinesa, então fiz um script em Go para imprimir direto por BLE
    Em vez de descompilar o app Android, deixei isso com uma IA agentic, e agora já existe uma versão para navegador e outra para ESP32
    Escrevi sobre isso em Making a label printer work under Linux using Agentic AI

• O motivo de eu ter rido ao ver o comando curl -fsSL https://fluid.sh/install.sh | bash foi a ironia de que,
  enquanto a intenção original era bloquear acesso por SSH por segurança, o resultado foi fazer o usuário executar um script de instalação ainda mais arriscado
  O tweet relacionado pode ser visto aqui

  • Hoje em dia vivemos num mundo em que colocam veneno na internet para fazer a LLM recomendar URLs maliciosas. Tempos incríveis

• Eu sou o Collin e estou criando o fluid.sh
  Pense nisso como uma versão de infraestrutura do Claude Code.
  O Fluid cria uma réplica em sandbox da infraestrutura de produção (VMs, K8s etc.), para que agentes de IA possam executar comandos, editar arquivos e rodar testes,
  e depois gerar IaC como um Ansible Playbook
  A ideia principal é permitir que a LLM explore o ambiente real e entenda o contexto, em vez de apenas gerar Terraform no vazio
  Por motivos de segurança, foi projetado para que o Claude Code não faça SSH diretamente na produção,
  e usa certificados SSH efêmeros para tornar a execução de comandos rastreável
  Em hosts com poucos recursos ou quando há acesso a redes externas, é exigida aprovação humana
  Feedback é bem-vindo!

  • Fico me perguntando por que essa explicação não está na página inicial.
    No site agora só está escrito algo como “Claude Code for infrastructure”,
    o que é informativo de menos para um engenheiro de infraestrutura sair dando bash numa linha dessas
  • Subir várias réplicas da infraestrutura para os agentes circularem parece desperdício de custo
    Do ponto de vista de quem faz DevOps, isso é ineficiente
  • Fazer configuração manual num sandbox remoto não combina com a filosofia de Infrastructure as Code
    Eu já automatizo o suficiente com Pulumi, Tilt e Kubernetes
    O Claude também funciona bem nesse ambiente. Não há necessidade de mexer diretamente via SSH
  • Então eu não entendo qual é a diferença em relação a simplesmente implantar e rodar o Claude Code numa VM existente
    Já existem vários métodos de sandbox. Quero entender o diferencial
  • Também dá para replicar infraestrutura existente com o Terraformer,
    e se essa automação básica de IaC não existe, então o problema é da equipe de DevOps
  • Eu já faço coisas como “mandar o Claude Code rodar comandos kubectl e corrigir charts Helm”
    Com CLI comum isso já funciona muito bem
    • Hoje em dia uma boa parte dessas ferramentas baseadas em LLM está nesse nível de wrapper de prompt. Não existe diferença essencial
    • Eu também sinto algo parecido, mas este projeto parece ter como objetivo garantir segurança em ambientes grandes
      Quando você opera na escala de centenas de VMs, simples supervisão não basta
    • Eu também rodo o Claude com conta somente leitura, e ele se integra bem com Terraform e AWS CLI
      Não preciso necessariamente de uma nova ferramenta
    • Eu também imponho limites com kubeconfig somente leitura, e basta escrever bem o SKILL.md para operar com segurança
    • Mesmo deixando em somente leitura, não tive grandes problemas.
      Ainda assim, este projeto parece enfatizar mais reprodutibilidade e segurança
  • Replicar produção não é simples. Conexões com banco de dados ou cópia da stack inteira são difíceis na prática
    Eu até acho melhor a IA entender a estrutura de produção e alterar diretamente
    Os modelos já são competentes o bastante para escrever IaC
  • A ideia é interessante. A área de operações e observabilidade (Observability) está em alta hoje
    Eu também dou ao Claude acesso ao Grafana para ajudar no debugging durante operações com Kubernetes,
    e isso me poupou dezenas de horas.
    A abordagem de gerar Ansible Playbooks automaticamente também é excelente do ponto de vista de rastreabilidade de auditoria
    • Mas se esse tipo de automação se espalhar, a instabilidade para quem trabalha em operações pode aumentar
      Já estão surgindo casos reais de engenheiros experientes perdendo o emprego
    • Fiquei animado ao saber que há planos para suporte a Kubernetes. Gostei da ideia
  • Sinceramente, acho que isso já é um problema resolvido
    Na maioria dos casos a infraestrutura já é montada com IaC desde o começo e, se necessário, pode ser reconstruída ao contrário
    Basta rodar o Claude numa conta sandbox com papel IAM
  • Não concordo com a afirmação de que “a LLM não consegue inferir bem sistemas de produção”
    IaC permite consultar a infraestrutura via API, e suas vantagens são reutilização e controle de versão
    • Concordo que ambientes DevOps variam de empresa para empresa e que é difícil generalizar
      A maioria das startups ainda sofre no nível de HCL ou YAML
  • A frase “para fazer isso com segurança, execute um script via curl” soa irônica
  • Por acaso a estrutura é algo como controlar KVM com libvirt e emitir chaves SSH para a LLM acessar a VM?
    O Ansible Playbook é gerado com base nas mudanças dentro da VM, ou tudo é manipulado apenas via Ansible?
    Quero entender qual é a função diferencial disso em relação a simplesmente rodar Ansible repetidamente