मेरा होमलैब AI डेवलपमेंट प्लेटफ़ॉर्म

 (rsgm.dev)
8 पॉइंट द्वारा GN⁺ 6 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • होमलैब सर्विस मैनेजमेंट के लिए OpenCode Web UI को Git access के साथ जोड़ा गया, और AI द्वारा किए गए बदलाव PR review के बाद GitOps से deploy होने वाले flow में व्यवस्थित किए गए
  • लगभग 12 docker compose स्टैक्स को Arcane में शिफ्ट करके GitOps से मैनेज किया जा रहा है, और AI टूल्स का उपयोग सर्विस मेंटेनेंस के लिए किया जा रहा है
  • कंटेनर अपडेट के समय release notes देखना, breaking changes की जांच करना, और manual verification में कई घंटे लगते थे, लेकिन अब release notes का summary कुछ मिनटों में पढ़कर version upgrade आसान और सुरक्षित हो गया है
  • OpenCode सर्वर के रूप में चलता है और terminal, file browser, Git diff, git worktree देता है, साथ ही कई डिवाइसों में persistent coding sessions को sync करता है
  • AI को वास्तविक सर्विस तक सीधे पहुंच नहीं है और वह केवल Git branches push कर सकता है, इसलिए review न किया गया code deploy नहीं हो सकता

होमलैब प्रबंधन flow

  • OpenCode Web UI को Git access देकर होमलैब प्रबंधन आसान बनाया गया, और जब OpenCode Git में बदलाव push करता है, तब इंसान PR approve करने के बाद GitOps उन बदलावों को deploy करता है
  • OpenCode सर्वर के रूप में चलता है, और persistent coding sessions कई डिवाइसों में sync होते हैं
  • मैनेज की जा रही सर्विसेज लगभग 12 docker compose स्टैक्स हैं, जिन्हें हाल ही में Arcane में शिफ्ट करके GitOps से मैनेज और deploy किया जा रहा है
  • AI टूल्स का पहला उपयोग मामला container updates था
    • पहले हर सर्विस के release notes ढूंढने पड़ते थे, breaking changes जांचनी पड़ती थीं, updates चलाने पड़ते थे, और हर सर्विस की समस्याओं को manually verify करना पड़ता था
    • इस प्रक्रिया में कई घंटे लगते थे, लेकिन अब release notes का summary कुछ मिनटों में पढ़कर version upgrade आसान और सुरक्षित हो गया है
    • ज़्यादातर कंटेनरों में healthcheck जोड़ने के लिए AI का उपयोग किया गया, जिससे समस्याएं जल्दी पकड़ में आने लगीं

OpenCode

  • पहले मुख्य रूप से Claude Code का उपयोग किया गया, लेकिन AI providers token limits के कारण customer value कम कर रहे हैं, इसलिए दूसरे विकल्पों को देखना पड़ा
  • ज़रूरत ऐसे टूल की थी जो किसी खास vendor पर निर्भर न हो और जिसमें प्रमुख plugins द्वारा समर्थित coding environment हो
  • कई coding environments आज़माने के बाद OpenCode चुना गया, और आज़माए गए विकल्पों में यह सबसे पसंदीदा टूल था
  • OpenCode में built-in web server और web UI होने की वजह से होमलैब AI development platform का विचार बना

AI डेवलपमेंट प्लेटफ़ॉर्म

  • Truenas host पर बुनियादी development tools वाला एक साधारण VM बनाया गया और OpenCode web server को systemd unit के रूप में जोड़ा गया
  • यह environment built-in terminal, file browser, Git diff, और git worktree support देता है, जिससे एक साथ कई coding sessions मैनेज किए जा सकते हैं
  • OpenCode का mobile web UI सवाल-जवाब popup के मामले में बहुत अच्छा लगा
  • Git server पर OpenCode के लिए अलग user और dedicated SSH key दी गई
    • OpenCode projects clone कर सकता है और branches push कर सकता है
    • deploy branch पर सीधे push नहीं कर सकता
  • workflow में AI को PR review के बाद रखा गया है, जहां OpenCode बदलाव लिखता है और इंसान PR में सीधे merge करता है
    • यह संरचना review न किए गए code के deploy होने से रोकती है
  • VM इंटरनेट और Git server तक पहुंच सकता है, लेकिन वास्तविक सर्विसेज तक नहीं पहुंच सकता
    • impact scope छोटा होने की वजह से, build tools या test dependencies install करने की ज़रूरत पड़ने पर OpenCode को VM root privileges देना स्वीकार्य माना गया
  • यह संरचना preinstalled tools, access guardrails, और audit logs वाले developer-focused ephemeral containers जैसी production developer platform में बढ़ाई जा सकती है
  • मौजूदा setup ज़रूरी फीचर्स देता है और components भी बहुत ज़्यादा नहीं हैं

Workflow

  • बुनियादी workflow OpenCode में feature या improvement की planning से शुरू होता है
    • planning में spec, implementation plan, और self-review शामिल होते हैं
  • जहां संभव हो, बदलावों को test या validate किया जाता है
  • जो हिस्से पसंद नहीं आते, उन्हें OpenCode के साथ iteratively सुधारा जाता है
  • OpenCode बदलावों को feature branch पर push करता है
  • उसी branch से PR खोला जाता है, और संतुष्ट होने पर PR merge किया जाता है
  • merge के बाद GitOps deployment संभाल लेता है
    • docker service changes को Arcane संभालता है
    • Home Assistant configuration changes को GitOps plugin संभालता है
    • blog changes को Cloudflare Pages worker संभालता है

Arcane GitOps और OpenCode का संयोजन

  • सर्विसेज को Truenas से Arcane GitOps project में शिफ्ट किया गया, और मुख्य उद्देश्य Truenas पर चल रहे सभी docker compose स्टैक्स को Git-based repository से मैनेज करना था
  • जब OpenCode को साथ में जोड़ा गया, तो यह तरीका उम्मीद से बेहतर काम करने लगा
  • फोन से सभी कंटेनरों की networking update की जा सकती है, जिससे बिखरी हुई configuration management काफी आसान हो गई
  • पहले सभी compose स्टैक्स को खंगालने और network connections ट्रैक करने में कई घंटे लगते थे
  • अब OpenCode को codebase और goal दिया जा सकता है, generated PR changes review किए जा सकते हैं, और फिर merge किया जा सकता है

बची हुई सीमाएं और access control

  • सबसे बड़ा खाली हिस्सा CI feedback है
  • GitHub पर coding agents Actions logs देखकर failed tests, linter errors, stack traces, और IaC plan changes diagnose कर सकते हैं
  • यह तरीका unit tests से बाहर की changes पर भी तेज feedback loop बनाए रखने में मदद करता है
  • Forgejo में यह flow अधिक कठिन है
    • Forgejo Actions public API के जरिए job logs expose नहीं करता
    • undocumented API मौजूद है, लेकिन उस API पर आधारित setup नहीं बनाना चाहते
  • मौजूदा setup AI को target services तक सीधे पहुंच दिए बिना, किसी भी डिवाइस से home infrastructure changes बनाने देता है
  • कंप्यूटर पर बदलाव शुरू किए जा सकते हैं, फोन पर PR review किया जा सकता है, और deployment GitOps पर छोड़ा जा सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 6 시간 전
Hacker News की राय

  • मैं अभी भी अपने environment के हिसाब से AI integration approach ढूँढ रहा हूँ। अभी Forgejo और coding agent के बीच interaction नहीं है, और Forgejo Actions runner भी आज़माया था, लेकिन context management थोड़ा अस्पष्ट लगा।
    issue या PR में जो है वह लिया जा सकता है, लेकिन कई बार back-and-forth हो या चर्चा issue से PR में चली जाए तो बात जल्दी धुंधली हो जाती है

  • मैं भी कुछ ऐसा ही कर रहा हूँ, लेकिन persistent opencode server की जगह Forgejo action runner के अंदर opencode चलाने वाला workflow इस्तेमाल कर रहा हूँ: https://codeberg.org/dragonfyre13/forgejo-opencode
    अभी भी इसमें सुधार कर रहा हूँ, लेकिन मूल विचार यह है कि Forgejo issue के अंदर /oc से Opencode को बुलाओ, और वह review के लिए PR बनाकर वापस आए

    • मैंने Claude Code और Forgejo के साथ भी कुछ ऐसा ही किया था, और वह Docker में Claude चलाने वाली एक छोटी अलग app के रूप में था: https://github.com/smithy-ai/smithy-ai

  • टेक industry में अक्सर लगता है कि बहुत से लोग लगभग एक ही समय पर मिलती-जुलती चीज़ें independently झेल रहे होते हैं, लेकिन उन्हें लिखने या share करने वाले लोग कम होते हैं।
    मैं भी ऐसा ही system बना रहा हूँ, इसलिए यह पोस्ट और comments देखकर अच्छा लगा कि सब लोग लगभग एक ही प्रक्रिया से गुजर रहे हैं

    • यह सिर्फ टेक industry की बात नहीं है, यह आम बात है। हम उतने original नहीं हैं
    • मैंने भी इसे तीन तरीकों से बनाया है, और e2b.dev भी इस्तेमाल किया है, जो अच्छी service थी।
      समस्या यह है कि समय का 99% शानदार चीज़ें hack करने में जाता है और सिर्फ 1% बोलने में। हमें ज़्यादा बोलना चाहिए
    • शायद इसकी वजह यह है कि टेक industry के लोग हर चीज़ मुफ्त में उम्मीद करते हैं।
      मैं एक वकील से बात कर रहा था और समय लगभग खत्म हो गया था, तो मैंने कहा “बस एक सवाल और”, और वकील ने कहा, “30 मिनट और बुक कीजिए, फिर उस पर बात करते हैं।” यह उचित तरीका है

  • मैं अपने AI lab के बारे में लिखने की motivation ढूँढ रहा था, और यह पोस्ट वही trigger थी जिसकी मुझे ज़रूरत थी।
    मेरा setup भी कुछ इसी तरह का है, लेकिन मैं n8n/git/argo/k3s इस्तेमाल करता हूँ, और यह मुख्य रूप से उन automation workflows के लिए है जिन्हें Qwen या Gemma4 संभाल सकते हैं

  • मैं जानना चाहता हूँ कि क्या किसी को पता है कि यह domain Quad9 resolver पर क्यों block हो रहा है। Quad9 domain को filter कर रहा है, इसलिए website खुल नहीं रही।
    dig @9.9.9.9 rsgm.dev NS के result में EDE: 17 (Filtered) आता है

    • मेरा अंदाज़ा है कि शायद registration बहुत नया होने की वजह से ऐसा हो। इसे register हुए लगभग 8 घंटे ही हुए हैं, और creation time 2026-06-15 14:01:25 UTC है

  • मैं अभी तक यह setup इस्तेमाल नहीं कर रहा, उसके दो मुख्य कारण हैं: project build के लिए opencode चलाने वाले VM को देनी पड़ने वाली resources, और तेज़ testing की ज़रूरत।
    मैं pi coding agent को सीधे Mac पर चलाता हूँ, और redis, postgres, kratos जैसे पूरे software bundle भी साथ चलाता हूँ। जब coding agent मुख्य development machine पर चलता है, तो build तेज़ होती है, और सिर्फ backend को दोबारा build करके restart करने के बाद UI client में बदलाव तुरंत test कर सकता हूँ

  • मैं भी लगभग यही कर रहा हूँ। मैं Proxmox LXC में OpenCode चलाता हूँ, और उसके ऊपर Kimaki layer जोड़कर Discord integration लगाया है।
    पसंद हो या न हो, codebase के साथ chat किया जा सकता है, और अगर पसंद हो तो voice message भी संभव है, जो काफ़ी शानदार है

  • बढ़िया। homelab AI बहुत मज़ेदार होने वाला लगता है।
    अभी मैं Claude से अपने सारे devices में फैले homelab को manage करा रहा हूँ, और homelab setup और maintenance अब “कई सालों तक आकर्षक लेकिन पूरी तरह सही कभी न चलने वाला और समय खा जाने वाला जाल” से बदलकर “वास्तव में अच्छा idea जो मेरी क्षमता बढ़ाता है” बन गया है

    • latest models इस्तेमाल करने पर भी समय बचाने वाले छोटे हिस्से तो हैं, लेकिन कुल मिलाकर अक्सर सूक्ष्म configuration issues की वजह से बहुत debugging करनी पड़ती है, इसलिए अंत में नुकसान ही होता है।
      “docker compose file बना दो” या “NSD config दे दो” जैसे बहुत narrowly defined कामों में यह ठीक है, लेकिन तब भी आपको पहले से पता होना चाहिए कि कौन-सी underlying technology चाहिए और क्या पूछना है

  • OpenCode Web UI में Git access जोड़कर homelab management आसान करना, और OpenCode Git में push करे, फिर मैं PR approve करूँ और GitOps उन changes को deploy करे — यह setup काफ़ी अच्छा लगता है।
    लेकिन पढ़ने से पहले मैं जानना चाहता हूँ कि क्या ऐसा कुछ करने के लिए RAM और GPU पर हज़ारों डॉलर खर्च करने पड़ेंगे

    • शायद 0 डॉलर भी लग सकते हैं। OpenCode बस एक harness है, इसलिए इसे online hosted किसी भी model से जोड़ा जा सकता है

  • हम भी कुछ ऐसा ही कर रहे हैं, लेकिन agent को PR खोलने की अनुमति भी है, और ReARM system से release metadata और agent sessions track करते हैं।
    हाल ही में agent के लिए ReARM के माध्यम से Helm-based deployments track करने का option भी जारी किया है: https://docs.rearmhq.com/workflows/devops.html

    • मैंने पोस्ट में यह हिस्सा नहीं बताया था, लेकिन लिखते समय समझ आया कि Forgejo PR API को call करने वाली skill आसानी से जोड़ी जा सकती है।
      अफ़सोस की बात है कि GitHub की तरह Forgejo में CLI नहीं है