Fluid - इन्फ्रास्ट्रक्चर के लिए Claude Code

• AI एजेंट वास्तविक इन्फ्रास्ट्रक्चर को सुरक्षित रूप से संभाल सकें, इसके लिए sandbox replica environment बनाने वाला एक terminal-आधारित टूल
• replicated VM या Kubernetes cluster में command execution, file modification, connection test करता है और परिणाम को अपने-आप Ansible Playbook के रूप में जनरेट करता है
• केवल LLM द्वारा code generation करने के तरीके से अलग, यह वास्तविक environment को replicate करके test और verification से गुज़रा हुआ IaC(Infra-as-Code) बनाता है
• ephemeral SSH certificates का उपयोग करके सुरक्षित रूप से commands चलाता है, और resource कम वाले host या internet access की स्थिति में human approval process आवश्यक होती है
• सभी commands और changes को audit log से ट्रैक किया जाता है, और यह developers को local environment में infrastructure पर प्रयोग करने और reproducible configuration बनाने में मदद करने वाला टूल है

---

Fluid का अवलोकन

• Fluid एक terminal agent है जो production infrastructure (जैसे VM, K8s cluster) की replica sandbox में AI को काम करने देता है
  • AI agent command execution, connection test, file editing कर सकता है
  • इसके बाद परिणाम को Ansible Playbook में बदलकर production environment पर लागू किया जा सकता है
• यह तरीका AI को वास्तविक system structure का अनुमान लगाने के बजाय replicated environment में सीधे प्रयोग करने देता है

मौजूदा LLM-आधारित IaC generation से अंतर

• LLM, Terraform, OpenTofu, Ansible आदि का code अच्छी तरह बना लेते हैं, लेकिन वास्तविक production environment के behavior को सटीक रूप से नहीं समझ पाते
• Fluid replicated infrastructure access के ज़रिए पहले command execution और testing करता है, और उन्हीं परिणामों के आधार पर IaC लिखता है
• यह approach deployment से पहले verification और experimentation संभव बनाती है

Claude Code से अंतर और security design

• Fluid को इस तरह design किया गया है कि Claude Code local से सीधे production server पर SSH access न करे
• सभी काम केवल sandbox के भीतर चलाए जाते हैं, और Fluid इसका प्रबंधन करता है
• ephemeral SSH certificates का उपयोग करके command execution के परिणाम real time में दिखाए जाते हैं
• memory या CPU कम वाले host, internet access, package installation आदि के लिए human approval process से गुजरना होता है

मुख्य विशेषताएँ

• Sandbox Isolation: VM को तुरंत replicate करके production को प्रभावित किए बिना changes को test करना
• Context-Aware: host के OS, package, CLI tools की जाँच करके environment के अनुसार काम करना
• Full Audit Trail: सभी commands और changes को रिकॉर्ड करके audit और review संभव बनाना
• Ansible Playbook auto-generation: sandbox में किए गए कार्यों के आधार पर reproducible infrastructure code बनाना

उपयोग उदाहरण

• Fluid v create_sandbox command से sandbox बनाता है और IP तथा status दिखाता है
• v run_command से command चलाई जाती है, और उदाहरण में Ubuntu 22.04 environment में Apache HTTP Server install और run किया जाता है
• curl localhost से web server के काम करने की पुष्टि की जाती है
• इसके बाद v create_playbook से httpd-setup playbook बनाई जाती है
  • इसमें 4 tasks शामिल हैं: apt cache update, Apache install, index.html बनाना, Apache service start और enable करना
• बनी हुई playbook दूसरे Ubuntu server पर भी वही configuration reproduce कर सकती है

इंस्टॉलेशन और संचालन

• local workstation पर install होने वाला terminal agent
  • install command:

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

• installation के बाद local environment से तुरंत sandbox creation और testing की जा सकती है

सारांश

• Fluid AI-आधारित infrastructure automation और security isolation को जोड़ने वाला टूल है
• real-time command execution, audit tracking, और Ansible code generation के ज़रिए यह सुरक्षित और reproducible infrastructure management को support करता है
• यह Claude Code का infrastructure version है, जो developers और operators को production environment की नकल करके प्रयोग करने का नया तरीका देता है

[GN⁺]

Hacker News की राय

• आजकल कुछ बनाने के लिए tools की भरमार है, लेकिन असल में क्या बनाया जाए, यही समझ नहीं आता
  ऐसा लगता है जैसे हर product किसी और build tool के लिए बने pyramid structure का हिस्सा हो
  यह fluid.sh की शिकायत नहीं है, बस मैं भी सोच रहा हूँ कि मुझे क्या बनाना चाहिए

  • मैं 2007 के Facebook app boom के दौरान एक startup में काम करता था, और हर app company का मॉडल दूसरे apps के ads बेचना था
    पूरा app ecosystem एक circular economy जैसा हो गया था, जिसमें न असली user value थी, न revenue source. आखिरकार यह ज़्यादा समय नहीं चला
  • समस्या यह है कि बहुत से developers domain knowledge के बिना सिर्फ software skills में ही गहराई तक जाते हैं
  • मैं भी पिछले 1 साल से non-tech industry में काम कर रहा हूँ, और coding skill की वजह से सहकर्मी मुझे जादूगर समझते हैं
    असली समस्याएँ हल करते-करते codebase धीरे-धीरे reusable features में बदल रहा है
    अब मैं इस अनुभव के आधार पर consulting आज़मा रहा हूँ, और शायद कभी कुछ ऐसा मिल जाए जिसे ‘product’ कहा जा सके
  • macroeconomics के नज़रिए से देखें तो जब technology बहुत तेज़ी से आगे बढ़ती है, तो एक ऐसा चरण आता है जहाँ output घटने लगता है
    अभी का AI tools boom भी कुछ वैसा ही लगता है. इतनी तेज़ी से बदलाव हो रहा है कि हर कोई फिर से सीख रहा है
    अंत में हम चलती रेत पर नींव बना रहे हैं
  • मैंने भी यही सोचा था, लेकिन हाल में मैंने ऐसे tools को reverse engineering में इस्तेमाल करना शुरू किया है
    उदाहरण के लिए, मुझे एक Chinese label printer की Linux print quality पसंद नहीं आई, तो मैंने BLE से सीधे print करने के लिए एक Go script बना ली
    Android app को decompile करने के बजाय मैंने यह काम Agentic AI को दे दिया, और अब इसका browser version और ESP32 version भी है
    इससे जुड़ी पोस्ट Making a label printer work under Linux using Agentic AI में लिखी है

• मैंने curl -fsSL https://fluid.sh/install.sh | bash command देखकर इसलिए हँसी,
  क्योंकि मकसद तो मूल रूप से security reasons से SSH access रोकना था, लेकिन नतीजा यह निकला कि उससे भी ज़्यादा जोखिमभरी install script चलानी पड़ रही है
  संबंधित tweet यहाँ देखा जा सकता है

  • अब तो हम ऐसी दुनिया में हैं जहाँ internet पर malicious URL LLM से recommend करवाने के लिए भी ज़हर फैलाया जाता है. क्या ज़माना आ गया है

• मैं Collin हूँ, और fluid.sh बना रहा हूँ
  इसे Claude Code का infrastructure version समझ सकते हैं.
  Fluid production infrastructure (VM, K8s आदि) की sandboxed replica बनाता है, ताकि AI agent commands चला सके, files बदल सके और tests कर सके,
  और फिर Ansible Playbook जैसी IaC बना सके
  मुख्य बात यह है कि LLM सिर्फ Terraform generate न करे, बल्कि असली environment को explore करके context भी समझे
  security reasons से इसे इस तरह design किया गया है कि Claude Code production में सीधे SSH login न कर सके,
  और ephemeral SSH certificates के ज़रिए command execution को trace किया जा सके
  कम resources वाले hosts या external network access की स्थिति में human approval माँगा जाता है
  feedback का स्वागत है!

  • समझ नहीं आता कि यह explanation homepage पर क्यों नहीं है.
    अभी site पर बस “Claude Code for infrastructure” जैसा कुछ लिखा है,
    जो infrastructure engineer के लिए एक लाइन bash install करने से पहले काफ़ी अपर्याप्त है
  • infrastructure की कई replicas खड़ी करके agents को उनमें घूमने देना cost waste जैसा लगता है
    DevOps के नज़रिए से यह inefficient है
  • remote sandbox में manual configuration करना Infrastructure as Code की philosophy के खिलाफ़ लगता है
    मैं Pulumi, Tilt, Kubernetes के साथ काफ़ी automation कर रहा हूँ
    Claude भी इस environment में ठीक काम करता है. SSH से सीधे छेड़छाड़ करने की ज़रूरत नहीं है
  • तो फिर यह existing VM पर Claude Code deploy करके चलाने से अलग कैसे है, यह समझ नहीं आ रहा
    sandboxing के कई तरीके पहले से हैं. differentiation क्या है, यह जानना चाहूँगा
  • Terraformer से existing infrastructure की replica भी बनाई जा सकती है,
    अगर ऐसी basic IaC automation नहीं है तो समस्या DevOps team में है
  • मैं पहले से ही “Claude Code से kubectl commands चलवाकर Helm chart fix करवाना” जैसा काम कर रहा हूँ
    सामान्य CLI के साथ भी यह काफ़ी अच्छे से काम करता है
    • आजकल LLM-based tools में से कई बस इसी तरह के prompt wrapper स्तर के हैं. कोई बुनियादी फर्क नहीं है
    • मुझे भी कुछ ऐसा ही लगा, लेकिन इस project का मकसद large-scale environments में safety सुनिश्चित करना है
      सैकड़ों VM वाली operations में सिर्फ simple monitoring काफ़ी नहीं होती
    • मैं भी Claude को read-only account पर चलाता हूँ, और यह Terraform या AWS CLI के साथ अच्छी तरह काम करता है
      नया tool लाने की ज़रूरत मुझे नहीं लगती
    • मैं भी read-only kubeconfig के साथ restrictions रखता हूँ, और SKILL.md ठीक से लिख दी जाए तो यह काफ़ी safely काम करता है
    • read-only access देकर भी कोई बड़ी समस्या नहीं हुई
      लेकिन यह project शायद reproducibility और safety पर ज़्यादा ज़ोर देता है
  • production replica बनाना आसान नहीं है. DB connections या पूरी stack की replica बनाना व्यवहारिक रूप से मुश्किल है
    इसके बजाय मुझे लगता है कि AI production structure को समझकर सीधे changes करे, यह बेहतर है
    models पहले ही IaC लिखने में काफ़ी सक्षम हैं
  • idea दिलचस्प है. आजकल operations·observability क्षेत्र काफ़ी उभर रहा है
    मैं भी Kubernetes operations के दौरान Claude को Grafana access देकर debugging में मदद लेता हूँ,
    और इससे दर्जनों घंटे बचे हैं.
    Ansible Playbook को auto-generate करने वाला approach auditability के हिसाब से भी शानदार है
    • लेकिन अगर ऐसी automation फैलती गई, तो operations workforce की instability बढ़ सकती है
      वास्तव में skilled engineers के jobs खोने के मामले भी सामने आ रहे हैं
    • Kubernetes support की planning है, यह सुनकर अच्छा लगा. idea पसंद आया
  • ईमानदारी से कहूँ तो मुझे यह पहले से solved problem लगता है
    ज़्यादातर लोग शुरुआत से infrastructure को IaC में बनाते हैं, और ज़रूरत हो तो बाद में reverse reconstruction भी कर सकते हैं
    Claude को sandbox account में IAM role के साथ चलाना काफ़ी है
  • मैं इस दावे से सहमत नहीं हूँ कि “LLM production systems के बारे में ठीक से अनुमान नहीं लगा सकता”
    IaC API के ज़रिए infrastructure को query कर सकता है, और reusability व version control इसका फायदा है
    • मैं इस बात से सहमत हूँ कि DevOps environments हर company में अलग होते हैं, और generalization मुश्किल है
      ज़्यादातर startups अभी भी HCL या YAML स्तर पर ही जूझ रहे हैं
  • “अगर इसे सुरक्षित करना है तो curl script चलाओ” यह पंक्ति काफ़ी विडंबनापूर्ण लगती है
  • क्या यह कुछ ऐसा है जिसमें KVM को libvirt से control किया जाता है और SSH keys issue करके LLM को VM access दिया जाता है?
    क्या Ansible Playbook VM के अंदर हुए changes के आधार पर generate होता है, या फिर सब कुछ सिर्फ Ansible से ही manipulate किया जाता है?
    मैं जानना चाहता हूँ कि सिर्फ Ansible को बार-बार चलाने की तुलना में इसमें कौन-सी differentiating features हैं