Fluid – Claude Code für Infrastruktur

 (fluid.sh)
5 Punkte von GN⁺ 2026-02-06 | 1 Kommentare | Auf WhatsApp teilen
  • Ein terminalbasiertes Tool, das eine Sandbox-Replikationsumgebung erstellt, damit AI-Agenten reale Infrastruktur sicher handhaben können
  • Führt Befehle aus, bearbeitet Dateien und testet Verbindungen in replizierten VMs oder Kubernetes-Clustern und erzeugt die Ergebnisse automatisch in Form von Ansible Playbooks
  • Anders als der Ansatz, bei dem ein LLM einfach nur Code generiert, repliziert es die reale Umgebung und erstellt getestete und validierte IaC (Infrastructure as Code)
  • Führt Befehle sicher mit ephemeren SSH-Zertifikaten aus; bei Hosts mit knappen Ressourcen oder bei Internetzugriff ist eine menschliche Freigabe erforderlich
  • Alle Befehle und Änderungen werden in einem Audit-Log nachverfolgt; ein Tool, mit dem Entwickler Infrastruktur lokal experimentell testen und reproduzierbare Konfigurationen erstellen können

Überblick über Fluid

  • Fluid ist ein Terminal-Agent, der AI in einer Sandbox arbeiten lässt, die Produktionsinfrastruktur (z. B. VM, K8s-Cluster) repliziert
    • Der AI-Agent führt Befehle aus, testet Verbindungen und bearbeitet Dateien
    • Anschließend können die Ergebnisse in Ansible-Playbooks umgewandelt und auf die Produktionsumgebung angewendet werden
  • Dieser Ansatz ermöglicht es der AI, nicht die Struktur realer Systeme zu erraten, sondern direkt in der replizierten Umgebung zu experimentieren

Unterschiede zu bisheriger LLM-basierter IaC-Erzeugung

  • LLMs erzeugen zwar gut Code für Terraform, OpenTofu, Ansible usw., verstehen aber das Verhalten realer Produktionsumgebungen nicht exakt
  • Fluid erstellt IaC auf Basis von vorheriger Befehlsausführung und Tests durch Zugriff auf replizierte Infrastruktur
  • Dieser Ansatz ermöglicht Validierung und Experimente vor dem Deployment

Abgrenzung zu Claude Code und Sicherheitsdesign

  • Fluid ist so konzipiert, dass Claude Code nicht direkt per SSH auf Produktionsserver im lokalen Umfeld zugreift
  • Alle Arbeiten werden ausschließlich innerhalb der Sandbox ausgeführt, die von Fluid verwaltet wird
  • Mit ephemeren SSH-Zertifikaten werden die Ergebnisse der Befehlsausführung in Echtzeit angezeigt
  • Bei Hosts mit wenig Arbeitsspeicher oder CPU, bei Internetzugriff oder Paketinstallation ist eine menschliche Freigabe erforderlich

Hauptfunktionen

  • Sandbox Isolation: Repliziert VMs sofort, um Änderungen zu testen, ohne die Produktion zu beeinflussen
  • Context-Aware: Erkundet OS, Pakete und CLI-Tools des Hosts und arbeitet passend zur Umgebung
  • Full Audit Trail: Zeichnet alle Befehle und Änderungen auf und ermöglicht Audit und Review
  • Automatische Erzeugung von Ansible-Playbooks: Erstellt auf Basis der in der Sandbox ausgeführten Arbeiten reproduzierbaren Infrastruktur-Code

Anwendungsbeispiel

  • Fluid erstellt mit dem Befehl v create_sandbox eine Sandbox und zeigt IP und Status an
  • Mit v run_command werden Befehle ausgeführt; im Beispiel wird in einer Ubuntu-22.04-Umgebung der Apache HTTP Server installiert und gestartet
  • Mit curl localhost wird die Funktion des Webservers verifiziert
  • Danach wird mit v create_playbook das Playbook httpd-setup erstellt
    • Enthält 4 Tasks: apt-Cache aktualisieren, Apache installieren, index.html erstellen, Apache-Dienst starten und aktivieren
  • Das erzeugte Playbook kann dieselbe Konfiguration auch auf anderen Ubuntu-Servern reproduzieren

Installation und Ausführung

  • Ein Terminal-Agent, der auf der lokalen Workstation installiert wird
  • Nach der Installation können Sandboxen und Tests sofort lokal erstellt und ausgeführt werden

Zusammenfassung

  • Fluid ist ein Tool, das AI-basierte Infrastrukturautomatisierung und Sicherheitsisolierung kombiniert
  • Mit Echtzeit-Befehlsausführung, Audit-Tracking und Erzeugung von Ansible-Code unterstützt es sicheres und reproduzierbares Infrastrukturmanagement
  • Als Infrastruktur-Version von Claude Code bietet es einen neuen Ansatz, mit dem Entwickler und Betreiber in produktionsnahen Umgebungen experimentieren können

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-06
Hacker-News-Kommentare

  • Heutzutage gibt es Unmengen an Tools zum Bauen, aber irgendwie nichts, das man tatsächlich bauen will.
    Es fühlt sich an, als wären alle Produkte nur Teil einer pyramidalen Struktur für weitere Build-Tools.
    Das ist keine Beschwerde über fluid.sh, ich überlege einfach selbst, was ich eigentlich bauen sollte.

    • Ich habe während des Facebook-App-Booms 2007 bei einem Startup gearbeitet, und alle App-Unternehmen verkauften im Grunde Werbung für andere Apps.
      Das App-Ökosystem lief wie eine geschlossene Kreislaufwirtschaft, ohne echten Nutzerwert oder tragfähige Erlösquellen. Am Ende hielt das nicht lange.
    • Das Problem ist, dass viele Entwickler sich ohne Domänenwissen nur tief in Softwaretechnik eingraben.
    • Ich arbeite jetzt seit einem Jahr in einer Nicht-Tech-Branche, und wegen meiner Programmierkenntnisse halten mich die Kollegen für einen Magier.
      Während ich reale Probleme löse, entwickelt sich die Codebasis nach und nach zu wiederverwendbaren Funktionen.
      Auf Basis dieser Erfahrung versuche ich mich jetzt an Consulting und finde irgendwann wohl auch etwas, das man ein „Produkt“ nennen kann.
    • Aus makroökonomischer Sicht gibt es einen Bereich, in dem zu schneller technologischer Fortschritt sogar zu sinkender Produktion führt.
      Der aktuelle AI-Tool-Boom wirkt auf mich ähnlich. Bei diesem schnellen Wandel lernen gerade alle wieder von vorn.
      Letztlich bauen wir auf beweglichem Sand.
    • Ich hatte dieselben Gedanken, nutze solche Tools in letzter Zeit aber für Reverse Engineering.
      Zum Beispiel war ich mit der Linux-Druckqualität eines chinesischen Etikettendruckers unzufrieden und habe deshalb ein Go-Skript gebaut, das direkt per BLE druckt.
      Statt die Android-App selbst zu dekompilieren, habe ich das einer Agentic AI überlassen, und inzwischen gibt es sogar eine Browser-Version und eine ESP32-Version.
      Mehr dazu steht in Making a label printer work under Linux using Agentic AI.

  • Ich musste bei dem Befehl curl -fsSL https://fluid.sh/install.sh | bash lachen,
    weil die eigentliche Absicht wohl war, SSH-Zugriff aus Sicherheitsgründen zu verhindern, man am Ende aber ironischerweise ein noch riskanteres Installationsskript ausführt.
    Den zugehörigen Tweet gibt es hier.

    • Wir leben inzwischen in einer Welt, in der man das Internet mit Gift füttert, damit LLMs bösartige URLs empfehlen. Wirklich erstaunliche Zeiten.

  • Ich bin Collin und baue fluid.sh.
    Man kann es sich als die Infrastruktur-Version von Claude Code vorstellen.
    Fluid erstellt Sandbox-Kopien von Produktionsinfrastruktur (VMs, K8s usw.), damit AI-Agenten dort Befehle ausführen, Dateien ändern und Tests laufen lassen können
    und anschließend IaC wie Ansible Playbooks erzeugen.
    Entscheidend ist, dass das LLM nicht nur Terraform generiert, sondern die reale Umgebung erkunden und den Kontext verstehen kann.
    Aus Sicherheitsgründen ist Claude Code so entworfen, dass es sich nicht direkt per SSH mit der Produktion verbindet,
    und mit ephemeren SSH-Zertifikaten lassen sich ausgeführte Befehle nachvollziehen.
    Bei Hosts mit knappen Ressourcen oder beim Zugriff auf externe Netzwerke ist eine menschliche Freigabe erforderlich.
    Feedback willkommen!

    • Ich frage mich, warum diese Erklärung nicht auf der Website steht.
      Dort steht aktuell nur so etwas wie „Claude Code for infrastructure“,
      und für einen Infrastruktur-Engineer ist das viel zu wenig, um einfach eine bash-Zeile auszuführen.
    • Mehrere Infrastruktur-Kopien hochzufahren und Agenten darin herumlaufen zu lassen, wirkt wie Ressourcenverschwendung.
      Aus DevOps-Sicht ist das ineffizient.
    • Manuelle Konfiguration in einer Remote-Sandbox passt nicht zur Infrastructure-as-Code-Philosophie.
      Ich automatisiere mit einer Kombination aus Pulumi, Tilt und Kubernetes bereits genug.
      Claude funktioniert in dieser Umgebung ebenfalls gut. Es muss nicht direkt per SSH eingreifen.
    • Dann verstehe ich nicht, worin der Unterschied dazu besteht, Claude Code einfach auf einer bestehenden VM bereitzustellen.
      Es gibt bereits mehrere Arten von Sandboxing. Mich interessiert das Alleinstellungsmerkmal.
    • Mit Terraformer kann man bestehende Infrastruktur ebenfalls kopieren.
      Wenn solche grundlegende IaC-Automatisierung nicht vorhanden ist, hat eher das DevOps-Team ein Problem.
    • Wir machen schon Dinge wie „Claude Code kubectl-Befehle ausführen lassen und Helm-Charts anpassen“.
      Das funktioniert auch mit einer normalen CLI bereits gut genug.
      • Ein großer Teil der aktuellen LLM-Tools ist letztlich nur ein solcher Prompt-Wrapper. Ein grundlegendes Unterscheidungsmerkmal gibt es nicht.
      • Ich sehe das ähnlich, aber dieses Projekt zielt wohl auf Sicherheitsgarantien für große Umgebungen ab.
        Wenn man Hunderte von VMs betreibt, reicht bloßes Beobachten nicht aus.
      • Ich betreibe Claude ebenfalls mit einem Read-only-Account, und es integriert sich problemlos mit Terraform oder der AWS CLI.
        Ein neues Tool brauche ich dafür nicht unbedingt.
      • Ich beschränke es ebenfalls mit einer Read-only-kubeconfig, und wenn SKILL.md sauber geschrieben ist, funktioniert das sicher genug.
      • Auch mit Read-only-Zugriff gab es bei mir keine größeren Probleme.
        Dieses Projekt scheint allerdings Reproduzierbarkeit und Sicherheit stärker zu betonen.
    • Eine Produktionskopie ist nicht trivial. DB-Verbindungen oder die Replikation eines kompletten Stacks sind in der Praxis schwer umzusetzen.
      Ich halte es fast für sinnvoller, wenn die AI die Produktionsstruktur versteht und Änderungen direkt dort vornimmt.
      Die Modelle sind inzwischen schon ziemlich gut darin, IaC zu schreiben.
    • Die Idee ist interessant. Gerade der Bereich Operations und Observability gewinnt an Bedeutung.
      Ich betreibe selbst Kubernetes und habe Claude Zugriff auf Grafana gegeben, damit es beim Debugging hilft,
      und das hat mir Dutzende Stunden gespart.
      Der Ansatz, Ansible Playbooks automatisch zu erzeugen, ist auch im Hinblick auf Auditierbarkeit hervorragend.
      • Wenn sich solche Automatisierung weiter verbreitet, könnte allerdings die Unsicherheit für Betriebsteams zunehmen.
        Es gibt bereits Fälle, in denen erfahrene Engineers ihre Jobs verlieren.
      • Es klingt vielversprechend, dass Kubernetes-Unterstützung geplant ist. Die Idee gefällt mir.
    • Ehrlich gesagt halte ich das für ein bereits gelöstes Problem.
      Die meisten setzen ihre Infrastruktur ohnehin von Anfang an als IaC auf und können sie bei Bedarf auch rückwärts rekonstruieren.
      Es reicht, Claude in einem Sandbox-Account mit IAM-Rolle laufen zu lassen.
    • Der Aussage „Ein LLM kann ein Produktionssystem nicht gut genug erschließen“ stimme ich nicht zu.
      IaC kann Infrastruktur über APIs abfragen, und Wiederverwendbarkeit und Versionsverwaltung sind klare Vorteile.
      • Ich stimme zu, dass DevOps-Umgebungen je nach Unternehmen sehr unterschiedlich sind und sich schwer verallgemeinern lassen.
        Die meisten Startups kämpfen immer noch mit HCL oder YAML.
    • Der Satz „Um sicher zu sein, führen Sie bitte ein curl-Skript aus“ wirkt ironisch.
    • Ist das hier vielleicht eine Architektur, bei der KVM über libvirt gesteuert wird und SSH-Schlüssel ausgegeben werden, damit das LLM auf VMs zugreifen kann?
      Werden die Ansible Playbooks auf Basis von Änderungen innerhalb der VM erzeugt, oder wird ausschließlich über Ansible gearbeitet?
      Mich würde interessieren, welche Unterscheidungsmerkmale es gegenüber einfachem wiederholtem Ausführen von Ansible gibt.