Devcontainer addon

रिपॉज़िटरी को एक पुनरुत्पाद्य, पृथक development container दें — ऐसा, जिसका उपयोग लोग, एडिटर और कोडिंग एजेंट सभी कर सकें। DWP v7 (पैक v7.9.0) में यह ऐडऑन devcontainer-kit को एकीकृत करता है — एक MIT उत्पाद जो Deep Work Plan के बिना भी काम करता है। यह वैकल्पिक है: इसके बिना भी एक रिपॉज़िटरी पूरी तरह अनुरूप होती है।

devcontainer-kit क्या प्रदान करता है

• एक टेम्पलेट, जो Dev Containers विनिर्देश पर आधारित है और जिसे dck init रिपॉज़िटरी में एक निश्चित लेआउट में रेंडर करता है: .devcontainer/devcontainer.json, docker/local/<service>/Dockerfile, docker/local/docker-compose.yaml और dev.sh। बाद में दोबारा चलाने पर यह समाधान (reconcile) करता है और आपके संपादनों को कभी अधिलेखित नहीं करता; किसी मौजूदा फ़ाइल में हर बदलाव पहले दिखाया जाता है और उसके लिए सहमति आवश्यक है।
• रिपॉज़िटरी का अपना container। Dockerfile runtime की आधिकारिक image से शुरू होता है, जो digest पर पिन की गई है — node-24, python-3.13 या debian — और kit के build चरणों को docker/local/<service>/dck/ में कॉपी करता है। कोई साझा base image शामिल नहीं है।
• dev.sh और dck। bash dev.sh up एक सामान्य टर्मिनल से container को build करता है, शुरू करता है और उससे जुड़ता है; shell, rebuild, doctor और बाकी कमांड VS Code या Cursor के साथ या उनके बिना काम करती हैं।
• दोनों दिशाओं में Herdr। होस्ट का Herdr हर container को केवल loopback पर सुनने वाले SSH सर्वर के माध्यम से एक मशीन के रूप में जोड़ता है, और container मानक साइडबार के साथ खुलता है: App, Editor, Development और Agents। हर workspace और pane, बाद में खोले गए भी, ऐप पाथ (डिफ़ॉल्ट रूप से /app) में शुरू होते हैं। भीतर, herdr-peers एजेंटों को होस्ट पर और दूसरे containers में मौजूद एजेंटों से पूछने देता है।
• dck-dockerfile skill। एक एजेंट अनुरोध पर किसी रिपॉज़िटरी का container बनाता या दोबारा उत्पन्न करता है और उसे एक वास्तविक build से सिद्ध करता है।

इंस्टॉल

git clone --branch v1.1.1 https://github.com/DailybotHQ/devcontainer-kit && ./devcontainer-kit/install.sh
cd your-repo && dck init && bash dev.sh up

आवश्यकताएँ: Linux या macOS होस्ट पर bash 3.2 या नया और python3 3.11 या नया, तथा container कमांड के लिए Compose v2 के साथ Docker। किसी रिलीज़ को उसके SHA256SUMS asset से सत्यापित करें। v1.1.1 पिन करें: v0.2.0 समर्थित नहीं है।

v1.0.0 से स्थिर। सार्वजनिक इंटरफ़ेस semantic versioning का पालन करता है और असंगत रूप से केवल नए मेजर संस्करण में बदलता है (और फ़ाइलों के लिए, नई इंटरफ़ेस संख्या के साथ): dck क्रियाएँ और उनके प्रलेखित फ़्लैग तथा एग्ज़िट कोड (0 ठीक, 1 विफल, 2 उपयोग, 3 कॉन्फ़िगरेशन, 4 परिवेश, 5 अस्वीकृत), dck.toml, होस्ट-प्रोफ़ाइल और dck doctor --json स्कीमा (इंटरफ़ेस 2), और रेंडर अनुबंध — वे फ़ाइलें जिन्हें dck init लिखता है और जिनका स्वामी है, वे dck:managed मार्कर और उपयोगकर्ता ब्लॉक जिन्हें यह सुरक्षित रखता है, तथा वह परिवेश जिसे entrypoint पढ़ता है। v0.3.7 से आगे बढ़ने पर कुछ नहीं टूटता: dck init और dck rebuild चलाएँ ताकि image में नए पिन आ जाएँ (herdr-peers v1.1.0, coding-agents-kit v1.1.0 और DeepWorkPlan Vim v1.0.1 पर)।

परतें

हर container में development टूल होते हैं — git, gh, ripgrep, एक SSH सर्वर, Herdr और herdr-peers — और कोई secret नहीं, जब तक आप होस्ट खातों को opt-in न करें। बाकी सब एक परत है जिसे आप dck.toml में चुनते हैं:

लॉगिन, gh, Herdr कॉन्फ़िगरेशन और git पहचान bash dev.sh rebuild के बाद भी बने रहते हैं। agents परत के साथ image में coding-agents-kit की तीन skills (agentkit, agentkit-setup, agentkit-orchestrate) भी होती हैं, जो हर start पर हर एजेंट की skills डायरेक्टरी में लिंक की जाती हैं, इसलिए दोबारा बनाया गया container भी उन्हें बनाए रखता है।

State volume (SSH होस्ट कुंजी, ~/.ssh, gh लॉगिन, Herdr क्लाइंट स्थिति, इतिहास) का नाम state है। जब कई services एक ही compose प्रोजेक्ट साझा करती हैं, तो dck.toml में [compose] state_volume से (या dck init --state-volume NAME से) हर एक को उसका अपना नाम दें; अन्यथा वे सभी एक ही volume mount करती हैं, और dck doctor यह बताता है।

मशीनों के पार एजेंट

v0.2.3 से, Docker Desktop पर dck up बिना किसी मैनुअल चरण के एक दो-तरफ़ा mesh जोड़ देता है:

• Container और होस्ट। भीतर के एजेंट होस्ट पर, हर दूसरे dck container में और उन अन्य loopback containers में मौजूद Herdr एजेंटों तक पहुँचते हैं जिन्हें आपके होस्ट का Herdr पहले से प्रबंधित करता है — और वे भी वापस पहुँचते हैं। हर पीयर एक पिन की हुई होस्ट कुंजी रखता है; पहले उपयोग पर किसी पर भरोसा नहीं किया जाता।
• एक वैकल्पिक होस्ट listener। dck setup एक बार, 127.0.0.1 पर एक उपयोगकर्ता-स्तरीय SSH सर्वर प्रस्तावित करता है जो केवल dck कुंजी स्वीकार करता है और जिसे launchd (macOS) चालू रखता है। यदि आप पहले से कोई loopback listener चलाते हैं, तो होस्ट प्रोफ़ाइल को उसी की ओर इंगित करें। dck host listener disable उसे हटा देता है।
• Rebuild के बाद भी बना रहता है। Container का Herdr मशीन कैटलॉग एक volume पर रहता है, इसलिए bash dev.sh rebuild भीतर पंजीकृत हर मशीन को बनाए रखता है। v0.3.2 से rebuild, start और restart वही चरण चलाते हैं जो up चलाता है: container फिर से होस्ट के Herdr में पंजीकृत होता है, उसकी होस्ट कुंजी फिर से पिन होती है और mesh भेजा जाता है, इसलिए शुरू से बना container तुरंत होस्ट और अपने peers तक पहुँचता है।
• Container के अंदर Codex पैन। दूसरी मशीनों के peers से पूछने के लिए Codex एजेंट को HERDR_PEERS_SELF चाहिए, यानी container की वह मशीन id जो होस्ट पर सहेजी गई है। v0.3.3 से kit हर पंजीकरण पर वह id दर्ज करता है और container के login shells उसे export करते हैं, इसलिए किसी एजेंट को उसे हाथ से सेट नहीं करना पड़ता; dck doctor किसी बेमेल को चिह्नित करता है। v0.3.4 से container के अपने Codex configs, Codex की startup अपडेट जाँच और उसके background daemon को छोड़ देते हैं (kit हर CLI का संस्करण पिन करता है), और आपके होस्ट की Codex home या किसी साझा प्रोफ़ाइल को कभी नहीं छूते।
• होस्ट से भी जवाब। dck setup होस्ट पर एक सत्यापित herdr-peers इंस्टॉल करता है, इसलिए dck agents और dck ask वहाँ भी काम करते हैं, और होस्ट के एजेंट herdr-peers reply से उत्तर देते हैं।
• वे containers जिन्हें kit ने नहीं बनाया। वे जिन सार्वजनिक कुंजियों से लॉगिन करते हैं, उन्हें अपनी होस्ट प्रोफ़ाइल में [ssh] authorized_extra के अंतर्गत सूचीबद्ध करें, और वे भी dck containers तक पहुँच सकेंगे।

होस्ट और container दोनों में इसे coding-agents-kit के साथ जोड़ें, और वही ak दोनों ओर एजेंट लॉन्च करता है।

कंटेनर के अंदर होस्ट खाते

एक कंटेनर उन खातों का उपयोग कर सकता है जो होस्ट पर आपके पास पहले से हैं, उसी तरह जैसे git पहले से होस्ट के SSH agent के माध्यम से काम करता है, अंदर किसी लॉगिन के बिना। यह opt-in है और आपकी होस्ट प्रोफ़ाइल में रहता है, कभी किसी रिपॉज़िटरी की dck.toml में नहीं:

[agents]
host_profiles = true          # default false
host_env_keys = ["ZAI_CODING_API_KEY"]   # allow-list of env names to share

host_profiles चालू होने पर, dck up केवल उन CLI की प्रोफ़ाइलें साझा करता है जिन्हें रिपॉज़िटरी इंस्टॉल करती है:

• Claude Code हर प्रोफ़ाइल के लिए एक दीर्घकालिक टोकन से: @default के लिए CLAUDE_CODE_OAUTH_TOKEN और @name के लिए CLAUDE_CODE_OAUTH_TOKEN_<SUFFIX> (suffix बड़े अक्षरों में, और A-Z, 0-9 तथा _ के बाहर का हर अक्षर _ में बदला हुआ)।
• Codex अपनी auth फ़ाइल से, @default के लिए और हर प्रोफ़ाइल के लिए।
• kit की env फ़ाइल, केवल-पढ़ने योग्य और host_env_keys के नामों तक सीमित।

पूरी agentkit home कभी mount नहीं की जाती, और जिन प्रोफ़ाइलों में होस्ट के absolute पथ हैं उन्हें छोड़ दिया जाता है। read-write साझा किया गया Codex लॉगिन एक साथ दो लेखकों द्वारा रीफ़्रेश किया जा सकता है: हर Codex खाते पर एक ही सक्रिय एजेंट रखें। होस्ट प्रोफ़ाइल में [agents] default_profile (उदाहरण के लिए { claude = "@work3" }) अंदर बिना तर्क वाले ak claude से उस साझा खाते का उपयोग करवाता है (coding-agents-kit ≥ v0.5.2); macOS पर @default Claude लॉगिन Keychain में रहता है और साझा नहीं किया जा सकता। v0.3.4 से container के shells बिना तर्क वाले claude या codex को भी उसी खाते की ओर इंगित करते हैं, इसलिए Herdr जिन पैन को बहाल करता है वे लॉगिन स्क्रीन के बजाय उसी खाते पर खुलते हैं। कंटेनर के अंदर, वही ak <kind> @<profile> होस्ट वाले खाते पर ही चलता है, और यही एक लीड को कंटेनर लेन को वे खाते सौंपने देता है जिन्हें ak pick ने चुना — देखें कई एजेंट चलाना।

कई रिपॉज़िटरी, एक compose stack

v0.3.3 से, जिस रिपॉज़िटरी की service किसी बड़े compose प्रोजेक्ट का एक हिस्सा है (एक API, एक वेब ऐप, workers और एक डेटाबेस, जो एक ही प्रोजेक्ट साझा करते हैं), वह dck द्वारा render की गई चीज़ों को हाथ से संपादित किए बिना उसमें शामिल हो सकती है। सब कुछ additive है: जो रिपॉज़िटरी इनमें से कोई भी कुंजी सेट नहीं करती, वह ठीक पहले की तरह render होती है।

• एक प्रोजेक्ट, हर service के लिए एक state volume। [compose] project हर रिपॉज़िटरी में साझा प्रोजेक्ट का नाम देता है; state_volume, [compose] networks और [compose] volumes हर service की स्थिति और stack के डेटा volumes तथा networks को अलग रखते हैं।
• एक user ब्लॉक। dck service के अंदर # >>> user:<service> >>> और # <<< user:<service> <<< के बीच की पंक्तियाँ ज्यों की त्यों रखी जाती हैं: जिन चीज़ों को dck render नहीं करता उनके लिए सामान्य कुंजियाँ (depends_on, healthcheck), और जिन कुंजियों को वह render करता है उनके लिए x-dck-merge:। जिस फ़ाइल में dck के केवल कुछ markers हों, उसे दोबारा लिखने के बजाय सुधार के तरीके के साथ अस्वीकार कर दिया जाता है।
• पोर्ट स्ट्रिंग्स। ssh_port और ports "${API_PORT:-8000}:8000" जैसे compose expressions स्वीकार करते हैं; जब तक स्ट्रिंग किसी होस्ट IP का नाम न ले, वे 127.0.0.1 पर ही रहते हैं।
• साझा builds और आपका अपना launcher। [build] context और [build] dockerfile कई services द्वारा साझा किए गए Dockerfile को संभालते हैं; dev_sh = false रिपॉज़िटरी की अपनी dev.sh को बनाए रखता है।
• Workspace satellites। v0.3.5 से, अपने ही compose प्रोजेक्ट में service का दूसरा instance dck के ज़रिए शुरू और बंद होता है (dck --project P --compose-file F --service S up या down), इसलिए उसे मुख्य instance जैसी ही होस्ट कुंजी, खाते, git पहचान और Herdr मशीन मिलती है; up --seed-state-from VOLUME केवल लॉगिन को उसके खाली state volume में कॉपी करता है। किसी overlay फ़ाइल में, extends को उस फ़ाइल का नाम देना होगा जिसे वह extend करता है।
• एजेंटों के लिए Node। एजेंटों का अपना Node /opt/dck/node के नीचे रहता है और image के Node की जगह कभी नहीं लेता; जब रिपॉज़िटरी के tooling को इसकी ज़रूरत हो, तो [agents] node_first = true इसे PATH में सबसे पहले रखता है।

कंटेनर के अंदर होस्ट की SSH कुंजियाँ

कुछ टूल केवल कुंजी फ़ाइलें पढ़ते हैं और forwarded agent को अनदेखा करते हैं: उदाहरण के लिए, gh auth login एक नई कुंजी बनाने की पेशकश करता है। v0.3.2 से आप इसे opt-in कर सकते हैं, केवल अपनी होस्ट प्रोफ़ाइल में (किसी रिपॉज़िटरी की dck.toml इसे सेट नहीं कर सकती; dck setup एक बार पूछता है, डिफ़ॉल्ट नहीं):

[ssh]
copy_keys = true              # default false

जब तक यह चालू है, dck up होस्ट के ~/.ssh को ~/.ssh_host पर read-only बाइंड करता है, और हर start उसकी id_* कुंजियों को container के ~/.ssh में कॉपी करता है (निजी कुंजियाँ 0600), होस्ट के साथ तालमेल में। Agent forwarding अपरिवर्तित रहता है, और इसे बंद करने पर अगले start पर प्रतियाँ हटा दी जाती हैं। इसकी कीमत: पूरा होस्ट ~/.ssh container के अंदर पढ़ा जा सकता है, और निजी कुंजियाँ state volume में रहती हैं।

सुरक्षा डिफ़ॉल्ट

• हर प्रकाशित port 127.0.0.1 से बाइंड होता है, जब तक dck.toml में bind सेट न हो।
• SSH पर git होस्ट के SSH agent से होकर जाता है — उसका socket, कभी कोई कुंजी फ़ाइल नहीं और कभी mount किया गया ~/.ssh या ~/.gitconfig नहीं, जब तक आपने अपनी होस्ट प्रोफ़ाइल में copy_keys चालू न किया हो। git पहचान DCK_GIT_* मानों से आती है, जिन्हें dck setup भरता है।
• SSH होस्ट कुंजियाँ runtime पर प्रति-प्रोजेक्ट volume में उत्पन्न की जाती हैं, कभी image में पहले से शामिल नहीं की जातीं; सर्वर केवल सार्वजनिक कुंजियाँ स्वीकार करता है, कोई root लॉगिन नहीं और कोई पासवर्ड नहीं।
• टेम्पलेट कोई cap_add, कोई privileged मोड और कोई Docker socket नहीं जोड़ता।
• हर डाउनलोड संस्करण पर पिन किया जाता है और checksum से सत्यापित होता है; base image digest पर पिन की जाती है।
• Herdr mesh, जो एक container के एजेंटों को दूसरों तक पहुँचने देता है, डिफ़ॉल्ट रूप से चालू है और kit के threat model में उसे बंद करने के तरीकों के साथ प्रलेखित है। होस्ट listener किसी चल रहे container के कोड को आपके रूप में होस्ट पर shell खोलने देता है: यह opt-in है, केवल loopback पर है, केवल dck कुंजी स्वीकार करता है और dck host listener disable से हट जाता है।

टिप्पणियाँ

वैकल्पिक और कभी आवश्यक नहीं। एक रिपॉज़िटरी शून्य वैकल्पिक ऐडऑन के साथ पूरी तरह अनुरूप होती है। Linux और macOS होस्ट समर्थित हैं; containers के बीच mesh के लिए Docker Desktop आवश्यक है।