Techstack v0.32.8 रिलीज़ (सोर्स
4c7d219a5d56) से जनरेट किया गया। इंस्टॉल किए गए वर्ज़न के लिए techstack api <command> --help ही प्रामाणिक है।techstack api stacks create
ओनर के Homelab में StackKit डिप्लॉयमेंट बनाएँ।stack_spec के रूप में दिए गए कैनोनिकल StackKits stack-spec पेलोड से, प्रमाणित B2C ओनर के एकमात्र Homelab के अंतर्गत एक आंतरिक StackKit डिप्लॉयमेंट बनाता है। लेगेसी /stacks रूट और stack_id रिस्पॉन्स फ़ील्ड उसी डिप्लॉयमेंट की पहचान करते हैं; वे कोई दूसरा Homelab प्रोडक्ट नहीं बनाते या नहीं चुनते। एक TechStack इंस्टेंस कई ओनर को सेवा दे सकता है, हर एक का अपना Homelab होता है। लेगेसी user_config/kombination पेलोड इस संगतता सीमा पर स्वीकार होते रहते हैं। विज़ार्ड क्लाइंट को स्थिर X-Idempotency-Key भेजनी चाहिए; उसी कुंजी और पेलोड के साथ दोबारा प्रयास मूल डिप्लॉयमेंट, नियोजित सर्वर और प्रोविज़निंग जॉब लौटाते हैं।
techstack api stacks deploy
एक StackKit डिप्लॉयमेंट रोल आउट करें (unify + IaC + tofu apply)।techstack api stacks destroy
एक StackKit डिप्लॉयमेंट और उसका इन्फ्रास्ट्रक्चर डीकमीशन करें।techstack api stacks drift check
ड्रिफ़्ट जाँच शुरू करें। हर 5 मिनट में एक बार तक सीमित (जब तक force=true न हो)techstack api stacks drift details
प्रभावित संसाधनों के साथ विस्तृत ड्रिफ़्ट जानकारी प्राप्त करें।techstack api stacks drift resolve
ड्रिफ़्ट समाधान शुरू करें (re-apply)। पूर्व-शर्त — स्टैक का स्टेटस “drifted” होना चाहिएtechstack api stacks drift status
वर्तमान ड्रिफ़्ट स्टेटस प्राप्त करें।techstack api stacks export
स्टैक को stack-spec.yaml के रूप में एक्सपोर्ट करें। Accept हेडर के अनुसार StackKits stack-spec YAML या JSON लौटाता हैtechstack api stacks import
stack-spec.yaml को StackKit डिप्लॉयमेंट के रूप में इम्पोर्ट करें। YAML या JSON को प्रमाणित ओनर के Homelab के अंतर्गत डिप्लॉयमेंट के रूप में इम्पोर्ट करता है।techstack api stacks intent
सहेजी गई kombination.yaml प्राप्त करें (byte-exact, base64)।techstack api stacks list
ओनर के StackKit डिप्लॉयमेंट सूचीबद्ध करें। प्रमाणित ओनर के एकमात्र B2C Homelab के अंतर्गत हर StackKit डिप्लॉयमेंट लौटाता है।kit_deployment_id, homelab_id और stackkit_id प्रोडक्ट पहचान हैं; जब तक उपभोक्ता माइग्रेट करते हैं, इस रूट पर लेगेसी पहचानकर्ता संगतता उपनाम के रूप में बने रहते हैं।
techstack api stacks managed-runtimes add
नेटिव प्रोवाइडर कंट्रोल के ज़रिए एक मैनेज्ड नोड जोड़ें। स्वामित्व वाले सटीक StackKit डिप्लॉयमेंट के लिए एक निर्धारक Add-Server जॉब बनाता है या फिर से शुरू करता है। मानकIdempotency-Key अनिवार्य है। उसी कुंजी को उसी कैनोनिकल रिक्वेस्ट के साथ रीप्ले करने पर मूल जॉब, लीज़, रनटाइम-सर्वर, रिसोर्स-जनरेशन और प्रोवाइडर-ऑपरेशन सहसंबंध लौटते हैं; अलग आशय के साथ उसका पुनः उपयोग 409 के साथ विफल होता है।
रॉ कुंजी कभी सहेजी या लौटाई नहीं जाती। खोया हुआ रिस्पॉन्स या अनिश्चित नेटिव-एडमिशन परिणाम केवल उसी कुंजी से फिर से शुरू किया जा सकता है। HTTP स्वीकृति का अर्थ है कि नेटिव एडमिशन टिकाऊ है और प्रोवाइडर रीकंसिलिएशन लंबित है; यह कभी दावा नहीं करता कि VM पहले से प्रोविज़न या स्वस्थ है। नया एडमिशन प्रमाणित टेनेंट/ओनर के क्षमता स्लॉट को लीज़ जनरेशन और प्रोवाइडर ऑपरेशन के साथ एटॉमिक रूप से आरक्षित करता है। जब आधिकारिक नेटिव एडमिशन पाता है कि वह सीमित क्षमता भरी हुई है, तो वह एक non-retryable 403 परिणाम सहेजता है और उस अस्वीकृत जॉब का रीप्ले वही परिणाम लौटाता है। पहले से कमिट हो चुके एडमिशन के सटीक रीप्ले उसका मौजूदा आरक्षण दोबारा उपयोग करते हैं। इस वर्ज़न में आरक्षण अपने आप रिलीज़ नहीं होता: केवल टर्मिनल या लोकल डीकमीशन स्टेट से स्लॉट खाली नहीं होता। लीज़ इन्वेंटरी और feature-delivery फ़्लैग कभी क्षमता अधिकृत या अस्वीकार नहीं करते। होस्टेड नए एडमिशन के लिए v2-हस्ताक्षरित वाणिज्यिक रनटाइम और प्रोवाइडर एंटाइटलमेंट तथा हस्ताक्षरित cloud.runtime.credits managed_servers मोड/सीमा निर्णय भी आवश्यक है; केवल फ़ीचर फ़्लैग कभी प्रोवाइडर क्षमता नहीं देते। सेल्फ़-होस्ट OSS, SaaS एंटाइटलमेंट निर्भरता के बजाय निर्माण के समय तय अपनी स्थिर रिलीज़-मैनिफ़ेस्ट नीति का उपयोग करता है।
techstack api stacks operations
स्वामित्व वाले एक StackKit डिप्लॉयमेंट का कॉन्फ़िगरेशन-पश्चात ऑपरेशन रीड मॉडल प्राप्त करें। TechStack ऑपरेशन डैशबोर्ड द्वारा उपयोग किया जाने वाला सटीक ओनर- और टेनेंट-स्कोप्ड रीड मॉडल लौटाता है।approved_servers ऑपरेटर स्वीकृति दर्ज करता है; connected_servers अधिक सख़्त है और केवल उन असाइन किए गए, स्वीकृत नोड को गिनता है जिनके पास ताज़गी-योग्य कैनोनिकल Guard हार्टबीट, कनेक्शन और हेल्थ प्रमाण हों। यह ऑपरेशन केवल-पढ़ने वाला है और कभी रोलआउट, प्रोविज़निंग या प्रोवाइडर कार्य शुरू नहीं करता।
techstack api stacks owner-spec
किसी StackKit डिप्लॉयमेंट का ओनर बूटस्ट्रैप स्पेक प्राप्त करें। लोकल ओनर फ़ील्ड और रिकवरी पासफ़्रेज़ हैश प्राप्त करने के लिए StackKit admin-bootstrap एंडपॉइंट। यह रूट केवलcreateStack द्वारा लौटाया गया अल्पकालिक बूटस्ट्रैप bearer टोकन स्वीकार करता है; यह सामान्य ब्राउज़र/सेशन bearer टोकन का उपयोग नहीं करता।
techstack api stacks pipeline-status
सभी स्पेक चरणों का पूरा पाइपलाइन स्टेटस प्राप्त करें।techstack api stacks provision
किसी मौजूदा StackKit डिप्लॉयमेंट की प्रोविज़निंग शुरू करें।techstack api stacks prune-orphans
ओनर-स्कोप्ड टेस्ट-अवशेष क्लीनअप की समीक्षा करें या उसे लागू करें। केवल कंट्रोल-प्लेन प्रक्षेपणों के लिए दो-चरणीय क्लीनअप।dry_run प्रमाणित ओनर के सटीक E2E/runtime-cloud उम्मीदवार और एक स्थिर रिविज़न-बद्ध डाइजेस्ट लौटाता है। apply प्लान की फिर से गणना करता है और केवल वही सटीक डाइजेस्ट स्वीकार करता है। यह रूट कभी लीज़ डीकमीशन नहीं करता, प्रोवाइडर को कॉल नहीं करता, इन्फ्रास्ट्रक्चर नष्ट नहीं करता और लाइफ़साइकल कार्य कतार में नहीं डालता।
techstack api stacks requirements
आवश्यकता स्पेक प्राप्त करें (चरण 1 आउटपुट)।techstack api stacks resume-enrollment
एक विलंबित मैनेज्ड नोड प्रतीक्षा को उसकी सटीक मौजूदा VM पर फिर से शुरू करें। सहेजे गएwaiting_enrollment, waiting_provider_provision या waiting_canonical_guard जॉब के लिए प्रमाणित, आइडेम्पोटेंट रिकवरी, जिसका next_resume_at सीमित ग्रेस अवधि से आगे विलंबित हो चुका है। सर्वर स्वामित्व वाले StackKit डिप्लॉयमेंट, सोर्स जॉब, प्रतीक्षा कारण, सटीक लीज़, सक्रिय फ़ाउंडेशन भूमिका और कैनोनिकल नोड को एक ही ऑपरेशन में सत्यापित करता है। यह सटीक सोर्स प्रतीक्षा को एटॉमिक रूप से समाप्त करता है, उसी लीज़ और नोड से बद्ध एक निर्धारक प्रतिस्थापन डिप्लॉय बनाता या फिर से तैयार करता है, और बाद की कॉल पर उसी जॉब को रीप्ले करता है। हैंडलर में प्रवेश से पहले कतार वर्कर टिकाऊ tenant/stack संगतता निष्पादन दावा एटॉमिक रूप से प्राप्त करते हैं; इससे Techstack रेप्लिका में एक ही StackKit डिप्लॉयमेंट के अलग-अलग जॉब क्रमबद्ध होते हैं। हैंडलर के बाहर निकलने तक, रद्दीकरण के दौरान भी, दावा टिकाऊ रूप से running रहता है। यह एंडपॉइंट कभी प्रोवाइडर VM निर्माण शुरू नहीं करता और न ही कोई नई VM चुनता है। क्रैश के बाद टिकाऊ running में मिला प्रतिस्थापन फ़ेल-क्लोज़्ड रहता है, उसी जॉब के रूप में रिपोर्ट होता है और कभी अपने आप डुप्लिकेट नहीं होता; रनटाइम-एक्शन रीकंसिलिएशन ऑपरेटर का अलग विषय रहता है।
techstack api stacks retry-rollout
एक विफल StackKit डिप्लॉयमेंट रोलआउट को उसकी सटीक मौजूदा मैनेज्ड VM पर फिर से आज़माएँ। स्वामित्व वाले विफल डिप्लॉय, उसकी सटीक सक्रिय फ़ाउंडेशन लीज़ और कैनोनिकल नोड को एक सर्वर-साइड ऑपरेशन में सत्यापित करता है। निर्धारक टिकाऊ प्रतिस्थापन प्रोवाइडर VM निर्माण को बायपास करता है, हैंडलर में प्रवेश से पहले टिकाऊtenant/stack संगतता निष्पादन दावा हासिल करता है, और इस ऑपरेशन की बार-बार की कॉल पर रीप्ले होता है। दावा रेप्लिका में एक ही StackKit डिप्लॉयमेंट के अलग-अलग जॉब क्रमबद्ध करता है और प्रोसेस क्रैश के बाद ऑपरेटर रीकंसिलिएशन तक running के रूप में फ़ेल-क्लोज़्ड रहता है।
techstack api stacks routing ensure
एक सटीक StackKit डिप्लॉयमेंट और नोड के लिए वांछित रूटिंग ओवरले सुनिश्चित करें। उपयोगकर्ता के अपरिवर्तनीय आशय को बदले बिना एक आइडेम्पोटेंट, रिविज़न वाला रूटिंग ओवरले एटॉमिक रूप से सहेजता है। server_id हमेशा सटीक और अनिवार्य है। lease_id मैनेज्ड रनटाइम के लिए अनिवार्य है और लोकल/Basement रनटाइम के लिए छोड़ा जाता है, जिसकी कोई लीज़ नहीं होती। मैनेज्ड लक्ष्य के लिए, true ensure_rollout रिक्वेस्ट मौजूदा डिप्लॉय पाइपलाइन तभी भेजती है जब यह साबित हो जाए कि उसकी चुनी गई सक्रिय फ़ाउंडेशन लीज़ और कैनोनिकल नोड इसी सटीक लक्ष्य के बराबर हैं। API परिणामी जॉब को कभी पहले से लागू के रूप में रिपोर्ट नहीं करता। ओवरले केवल StackKits आर्टिफ़ैक्ट निकालते समय उपयोग होता है और यह रास्ता कभी कोई प्रतिस्थापन VM नहीं बनाता या नहीं चुनता।techstack api stacks routing get
एक StackKit डिप्लॉयमेंट की वांछित और देखी गई रूटिंग स्टेट पढ़ें। सटीक StackKit डिप्लॉयमेंट के लिए टेनेंट- और ओनर-बद्ध रूटिंग ओवरले लौटाता है। वांछित स्टेट और देखी गई/लागू स्टेट अलग-अलग रिपोर्ट होती हैं, ताकि क्लाइंट केवल सहेजे जाने से सफल DNS, TLS या StackKit रोलआउट का अनुमान न लगाएँ।techstack api stacks routing targets
एक StackKit डिप्लॉयमेंट के स्पष्ट प्राथमिक रूटिंग लक्ष्य सूचीबद्ध करें। सक्रिय RuntimeLease अथॉरिटी पर आधारित केवल-पढ़ने वाली डिस्कवरी। ओनर को दिखने वाला हर फ़ाउंडेशन/कंट्रोल-प्लेन लक्ष्य लौटाता है और कभी कोई लक्ष्य नहीं चुनता, कैनोनिकल नोड (ServerRuntime) प्रक्षेपण नहीं बनाता, या StackKit डिप्लॉयमेंट नहीं बदलता। कॉलर को रूटिंग बदलाव के लिए पूरा server_id और lease_id युग्म भेजना होगा।