सर्वर पर Claude Code सुरक्षित ढंग से चलाएँ

सर्वर पर Claude Code सुरक्षित ढंग से चलाने का मतलब क्या है

सर्वर पर Claude Code को सुरक्षित ढंग से चलाने का मतलब है: उसके परमिशन प्रॉम्प्ट चालू रखें, उसे एक समर्पित, बिना विशेषाधिकार वाले यूज़र के तौर पर चलाएँ, और बिना निगरानी वाले रन को भरोसे के बजाय एक असली सीमा दें: बिल्ट-इन सैंडबॉक्स, कोई कंटेनर, या एक डिस्पोज़ेबल VPS जिस पर ऐसा कुछ न हो जिसकी आपको परवाह हो। --dangerously-skip-permissions फ़्लैग मॉडल और आपके शेल के बीच से मंज़ूरी वाला क़दम हटा देता है। बिना निगरानी वाले काम के लिए यह सौदा वाजिब हो सकता है, पर सिर्फ़ ऐसी सीमा के भीतर जो तय कर दे कि एक ग़लत कमांड कहाँ तक पहुँच सकती है। यह गाइड बताती है कि वह फ़्लैग असल में क्या बदलता है, और उस सीमा को बढ़ते अलगाव की सीढ़ियों में कैसे बनाया जाए।

Claude Code आपकी मशीन पर क्या-क्या कर सकता है

Claude Code एक कोडिंग एजेंट है जो आपके टर्मिनल में चलता है। वह फ़ाइलें पढ़ता है, फ़ाइलें लिखता है, और उसी यूज़र के तौर पर शेल कमांड चलाता है जिसने उसे शुरू किया। टूल का असली फ़ायदा यही है: वह किसी रिपॉज़िटरी को clone कर सकता है, कोड बदल सकता है, टेस्ट चला सकता है, फ़ेल हुए टेस्ट का आउटपुट पढ़ सकता है और एक लूप में कोड ठीक करता जा सकता है, वह भी आपसे हर कमांड टाइप कराए बिना। अगर आपने इसे अब तक किसी सर्वर पर सेट नहीं किया है, तो VPS पर tmux में Claude Code चलाना इंस्टॉल और सेशन संभालने की बात करता है। यह पेज उस ताक़त के बारे में है जो वहाँ पहुँचने के बाद आप उसे सौंप देते हैं।

जोखिम भी वही वाक्य है, बस उसे दूसरी बार पढ़कर देखिए। जो प्रोसेस आपके यूज़र के तौर पर शेल कमांड चलाती है, वह वह सब कर सकती है जो आपका यूज़र कर सकता है। वह ~/.ssh/id_ed25519 पढ़ सकती है, ~/.aws/credentials पढ़ सकती है, और हर वह .env फ़ाइल पढ़ सकती है जिसे आपका यूज़र खोल सकता है। वह curl चलाकर हर उस होस्ट तक डेटा भेज सकती है जहाँ तक सर्वर पहुँच सकता है। वह git push --force चला सकती है। एजेंट का अपना कोई इरादा नहीं होता। ख़तरा यह है कि कोई काम बिगड़ जाए, या काम के दौरान उसने जो टेक्स्ट पढ़ा उसमें किसी और की लिखी हिदायतें छिपी हों: कोई वेब पेज जो उसने fetch किया, या किसी issue में लिखी वह टिप्पणी जिसे ठीक करने को कहा गया था। दूसरे मामले को prompt injection कहते हैं, और इसीलिए "मॉडल आम तौर पर समझदार है" कोई सुरक्षा योजना नहीं है। आप औसत रन के लिए नहीं, बिगड़े हुए रन के लिए योजना बनाते हैं।

परमिशन सिस्टम, सीधी भाषा में

डिफ़ॉल्ट रूप से Claude Code कुछ करने से पहले पूछता है। प्रोजेक्ट के भीतर फ़ाइलें पढ़ना चुपचाप होता है, पर कोई फ़ाइल बदलने या कोई शेल कमांड चलाने से पहले वह आपको ठीक वही बदलाव या वही कमांड दिखाता है और हाँ का इंतज़ार करता है। आप एक कार्रवाई को मंज़ूरी दे सकते हैं, या उस तरह की हर कार्रवाई को बाक़ी सेशन के लिए मंज़ूरी दे सकते हैं। ये मंज़ूरियाँ सेशन तक ही सीमित रहती हैं: CLI बंद करें, और अगला सेशन फिर से सावधान होकर शुरू होता है। जो नियम आप हमेशा के लिए रखना चाहते हैं, उनके लिए सेटिंग्स फ़ाइल में allow, ask और deny सूचियाँ रहती हैं। जैसे: git status को allow, git push पर ask, .env पढ़ने पर deny। deny नियम हमेशा जीतते हैं।

यह डिज़ाइन मानकर चलता है कि कोई इंसान टर्मिनल देख रहा है, और लैपटॉप पर यह सच भी है। सर्वर पर अक्सर बात ही यह होती है कि कोई नहीं देख रहा। आप tmux के भीतर एक लंबा काम शुरू करके सो जाते हैं, और रात दो बजे सवाल पूछने के लिए रुक गया एजेंट सुबह तक एक क़दम आगे नहीं बढ़ता। यह ठहराव सिर्फ़ वक़्त नहीं, पैसा भी ख़र्च कराता है, क्योंकि निष्क्रिय पड़ा Claude Code सेशन अपना गर्म प्रॉम्प्ट कैश खो देता है और अगली बारी उसे दोबारा बनाने की क़ीमत चुकाती है। सच यही है कि सर्वर पर लोग skip फ़्लैग की ओर इसीलिए हाथ बढ़ाते हैं, और यह समस्या असली है। बाक़ी गाइड इसी को हल करने की बात करती है, बचाव की हर परत छोड़े बिना।

--dangerously-skip-permissions क्या बदलता है

claude --dangerously-skip-permissions मंज़ूरी वाला क़दम बंद कर देता है। बदलाव बिना किसी प्रॉम्प्ट के होते हैं। शेल कमांड बिना किसी प्रॉम्प्ट के चलती हैं। संवेदनशील जगहों की रखवाली करने वाली protected-path जाँचें भी छूट जाती हैं। आपके साफ़-साफ़ लिखे deny नियम फिर भी लागू रहते हैं, और कुछ बेहद ख़तरनाक कार्रवाइयाँ अब भी पूछने के लिए रुकती हैं, पर काम की बात सीधी है: मॉडल जो भी चलाने का फ़ैसला करे, वह चल जाता है।

सर्वर पर इस फ़्लैग की दो बातें मायने रखती हैं। पहली, Linux और macOS पर जब Claude Code root के तौर पर या sudo के तहत चलता है, तो यह फ़्लैग रोक दिया जाता है, क्योंकि बिना प्रॉम्प्ट वाला root मशीन की किसी भी फ़ाइल या सर्विस को बदल सकता है। एजेंट को अपना अलग, बिना विशेषाधिकार वाला अकाउंट वैसे भी चाहिए, और यह फ़्लैग उसे ज़रूरी बना देता है। दूसरी, यह फ़्लैग मॉडल के व्यवहार में कोई बदलाव नहीं करता। वह लूप से इंसान को हटाता है और इसके सिवा कुछ नहीं बदलता, इसलिए जिस भी ग़लती को कोई प्रॉम्प्ट पकड़ लेता, वह अब चल जाती है।

तो सीधा हिसाब यह है। अगर आप परमिशन छोड़ देते हैं, तो सुरक्षा का सवाल "क्या एजेंट कुछ बुरा करेगा" से बदलकर "एक बुरी कार्रवाई कितना नुक़सान कर सकती है" हो जाता है। आप हर फ़ैसले पर क़ाबू पाने की कोशिश छोड़ देते हैं और नुक़सान के दायरे (blast radius) पर क़ाबू पाने लगते हैं। जवाब है घेराबंदी, और वह सीढ़ी-दर-सीढ़ी बनती है।

Claude Code का बिल्ट-इन सैंडबॉक्स

सीढ़ियों से पहले यह जान लें कि Claude Code अब अपनी चलाई जाने वाली कमांडों के लिए OS स्तर का एक सैंडबॉक्स साथ लाता है, और वह उन ज़्यादातर वजहों को हटा देता है जिनके चलते लोग skip फ़्लैग तक पहुँचते थे। Linux पर वह फ़ाइल सिस्टम के अलगाव के लिए bubblewrap इस्तेमाल करता है, और नेटवर्क ट्रैफ़िक को एक प्रॉक्सी से गुज़ारने के लिए socat। सैंडबॉक्स के भीतर कोई कमांड सिर्फ़ प्रोजेक्ट डायरेक्टरी और एक सेशन temp डायरेक्टरी में लिख सकती है, और नेटवर्क तक सिर्फ़ उस प्रॉक्सी से पहुँच सकती है जो हर डोमेन को एक allow सूची के सामने जाँचता है। जब कोई कमांड पहली बार किसी नए डोमेन तक जाना चाहती है, तो Claude Code आपसे पूछता है।

सेशन के भीतर /sandbox कमांड से इसे चालू करें। Ubuntu और Debian पर पहले वे दो पैकेज इंस्टॉल करें जिनकी उसे ज़रूरत है:

sudo apt install bubblewrap socat

Ubuntu 24.04 और उसके बाद के वर्ज़न पर डिफ़ॉल्ट AppArmor पॉलिसी bubblewrap को वे user namespace बनाने से रोक देती है जिनकी उसे ज़रूरत है। कोई चीज़ नदारद हो, तो सैंडबॉक्स पैनल आपको बता देता है, और Claude Code के sandboxing दस्तावेज़ों में वह छोटी-सी AppArmor प्रोफ़ाइल दी गई है जो इसे ठीक कर देती है।

सैंडबॉक्स में एक auto-allow मोड है: सैंडबॉक्स के भीतर चलने वाली कमांड बिना किसी प्रॉम्प्ट के चलती हैं, क्योंकि जो काम पहले प्रॉम्प्ट करता था, वह अब लागू की गई सीमा ख़ुद कर देती है। जो कमांड सैंडबॉक्स के भीतर नहीं चल सकतीं, वे सामान्य परमिशन फ़्लो पर लौट आती हैं, इसलिए सचमुच असामान्य कार्रवाइयाँ अब भी पूछती हैं। ज़्यादातर सर्वर वर्कफ़्लो में skip फ़्लैग की जगह यही लेना सही है, क्योंकि सवाल तब भी बहुत कम पूछे जाते हैं और सीमा ग़ायब रहने के बजाय OS से लागू होती है।

इसकी हदों के बारे में ईमानदार रहें। डिफ़ॉल्ट रूप से सैंडबॉक्स में चलने वाली कमांड फ़ाइल सिस्टम का ज़्यादातर हिस्सा अब भी पढ़ सकती है, क्रेडेंशियल फ़ाइलें भी, जब तक आप उन रास्तों पर deny न लगाएँ; sandbox.credentials सेटिंग ठीक इसी के लिए है। नेटवर्क प्रॉक्सी डोमेन नाम जाँचता है, ट्रैफ़िक की जाँच नहीं करता, इसलिए github.com जैसी चौड़ी allow अब भी डेटा बाहर भेजने की गुंजाइश छोड़ती है। Docker इसके भीतर काम नहीं करता। सैंडबॉक्स सुरक्षा का बुनियादी स्तर काफ़ी ऊपर उठा देता है। यह पूरा अलगाव नहीं है, और इसीलिए नीचे दी गई सीढ़ियाँ अब भी मायने रखती हैं।

घेराबंदी की सीढ़ी

तीन सीढ़ियाँ, बढ़ते अलगाव के क्रम में। मशीन पर और क्या-क्या रहता है, उसके हिसाब से सबसे नीचे वाली उपयुक्त सीढ़ी चुनें।

सीढ़ी 1: एक समर्पित, बिना विशेषाधिकार वाला यूज़र। एजेंट को अपना अकाउंट, अपनी होम डायरेक्टरी और अपनी प्रोजेक्ट डायरेक्टरी मिलती है, और sudo नहीं मिलता:

sudo adduser --disabled-password --gecos "" agent

अकाउंट की यह सीमा एजेंट को आपकी फ़ाइलों से दूर रखती है: आपकी SSH कुंजियों से, और मशीन पर मौजूद हर दूसरे प्रोजेक्ट से। इसी की वजह से skip फ़्लैग इस्तेमाल करने लायक़ भी बनता है, क्योंकि वह फ़्लैग root के तौर पर चलने से इनकार करता है। यह वही सिद्धांत है जो हर सर्विस को बिना विशेषाधिकार वाले यूज़र के तौर पर चलाने में है, बस एजेंट पर लागू। सीढ़ी 1 किन चीज़ों को नहीं बाँधती: नेटवर्क, और मशीन पर पड़ी हर वह चीज़ जिसे कोई भी यूज़र पढ़ सकता है।

सीढ़ी 2: एक कंटेनर। Anthropic एक रेफ़रेंस devcontainer प्रकाशित करता है जो Claude Code को non-root यूज़र के तौर पर चलाता है, ऐसे फ़ायरवॉल नियमों के साथ जो तय करते हैं कि एजेंट किन होस्ट तक पहुँच सकता है; ख़ुद बनाया हुआ कंटेनर भी यही काम करता है। फ़ाइल सिस्टम सिमटकर उन वॉल्यूम तक रह जाता है जिन्हें आप mount करते हैं, और बाहर जाने वाला ट्रैफ़िक सिमटकर उतना रह जाता है जितना कंटेनर के नियम देते हैं। जब सर्वर पर और भी ऐसी सर्विसें चल रही हों जिनकी आपको परवाह है, तो बीच की यही सही सीढ़ी है। इसकी हद यह है कि कंटेनर होस्ट का कर्नेल साझा करते हैं, और एक लापरवाह mount पूरी सीमा खोल देता है: कंटेनर को /var/run/docker.sock थमा दें, और वह पूरे होस्ट तक पहुँच जाता है।

सीढ़ी 3: एक समर्पित VPS। सबसे मज़बूत सीढ़ी सबसे सीधी है: एजेंट को एक पूरी मशीन दे दें जिस पर ऐसा कुछ न हो जिसकी आपको परवाह हो। एक छोटा VPS महीने के कुछ डॉलर में आता है। उसे नए VPS पर पहले 10 मिनट वाले रनबुक से सेट करें, साफ़-सुथरी हालत का snapshot लें, और एजेंट को काम करने दें। वहाँ और कुछ नहीं रहता। कोई निजी SSH कुंजी नहीं, सिर्फ़ एक deploy key जो उसी एक रिपॉज़िटरी तक सीमित है। कोई क्लाउड क्रेडेंशियल नहीं, कोई प्रोडक्शन डेटा नहीं। कोई रन बिगड़ जाए, या आप बस साफ़ शुरुआत चाहें, तो snapshot वापस ले आएँ या मशीन मिटाकर मिनटों में दोबारा बना लें। नुक़सान का पूरा दायरा यहाँ महीने भर के किराए जितना है। यही वह सेटअप है जहाँ --dangerously-skip-permissions डरावना नहीं रह जाता, क्योंकि सबसे बुरा वास्तविक नतीजा है एक दोबारा बनाया गया सर्वर और एक रद्द किया गया टोकन।

ये सीढ़ियाँ एक-दूसरे के ऊपर लगती भी हैं। सैंडबॉक्स में बंद एजेंट, बिना विशेषाधिकार वाले यूज़र के तौर पर, किसी डिस्पोज़ेबल VPS पर: इसमें अतिरिक्त ख़र्च लगभग शून्य है और फ़ेल्योर की कहानियाँ उबाऊ हो जाती हैं। उबाऊ होना ही लक्ष्य है।

क्रेडेंशियल की हिफ़ाज़त करें

वह एक नियम जिससे बाक़ी सारी मेहनत वसूल हो जाती है: एजेंट का यूज़र ऐसा कोई भी सीक्रेट न पढ़ पाए जो किसी और चीज़ का है।

API कुंजी सिर्फ़ एजेंट को दें, और किसी को नहीं। उसे ऐसी फ़ाइल में रखें जो एजेंट के यूज़र की हो और जिसका mode 600 हो, और शेल शुरू होने पर उसे लोड करें:

install -m 600 /dev/null /home/agent/claude.env
echo 'export ANTHROPIC_API_KEY=your-key-here' >> /home/agent/claude.env
echo 'source ~/claude.env' >> /home/agent/.bashrc

फिर दूसरी दिशा बंद करें। Debian और Ubuntu पर होम डायरेक्टरी अक्सर ऐसी बनती हैं जिन्हें मशीन का हर यूज़र पढ़ सकता है, इसलिए अपनी डायरेक्टरी कसें: chmod 750 /home/youruser। ls -ld /home/* से जाँचें और जिन डायरेक्टरी में एजेंट का अकाउंट झाँक सकता है, उन्हें ठीक करें।

हर टोकन का दायरा सीमित करें। एक ही रिपॉज़िटरी तक सीमित fine-grained GitHub टोकन, या प्रति-रिपॉज़िटरी deploy key का मतलब है कि लीक हुआ क्रेडेंशियल एक प्रोजेक्ट गँवाता है, आपका पूरा अकाउंट नहीं। सैंडबॉक्स इस्तेमाल कर रहे हों, तो उसकी क्रेडेंशियल सेटिंग्स जोड़ें ताकि ~/.ssh और ~/.aws पढ़ने के लिए भी deny हों। और प्रोडक्शन क्रेडेंशियल मशीन पर रखें ही नहीं, क्योंकि जो सीक्रेट वहाँ कभी था ही नहीं, एजेंट उसे लीक नहीं कर सकता।

Git ही सुरक्षा जाल है

एजेंट का किया हर बदलाव देखा जा सके और वापस लिया जा सके, यह ज़रूरी है; एजेंट किसी branch पर काम करे, तो git आपको दोनों मुफ़्त में देता है:

git switch -c agent/refactor-auth

बाद में git diff main...agent/refactor-auth से रन की समीक्षा करें, जो अच्छा है उसे merge करें, और रन कहीं न पहुँचा हो तो branch मिटा दें। forge की ओर से main branch को सुरक्षित कर दें, ताकि एजेंट का टोकन न उस पर push कर सके और न कहीं force-push कर सके। commit history साथ ही उस सबका ऑडिट लॉग बन जाती है जो आपके सोते समय हुआ, और यह किसी भी लंबे टर्मिनल स्क्रॉलबैक से ज़्यादा क़ीमती है।

नेटवर्क भी नुक़सान के दायरे का हिस्सा है

एजेंट curl चला सकता है। यही एक वाक्य बाहर जाने वाले ट्रैफ़िक (egress) की पूरी समस्या है: एजेंट जो कुछ पढ़ सकता है, उसे कहीं भेज भी सकता है, और prompt injection का शिकार बना एजेंट शायद भेज भी दे। अकेला बिना विशेषाधिकार वाला यूज़र इसे ज़रा भी नहीं बाँधता, क्योंकि कोई भी यूज़र वहाँ तक पहुँच सकता है जहाँ तक सर्वर पहुँच सकता है। सैंडबॉक्स अपने प्रॉक्सी के ज़रिए डोमेन के हिसाब से इसे बाँधता है। कंटेनर अपने फ़ायरवॉल नियमों से इसे बाँध सकता है। समर्पित VPS इस बात को ही बाँध देता है कि लीक होने लायक़ वहाँ है क्या, और तीनों में सबसे मज़बूत जवाब यही है।

अकेले ufw से egress हल करने की कोशिश न करें। ufw डिफ़ॉल्ट रूप से बाहर जाने वाला सारा ट्रैफ़िक जाने देता है, और ऐसे outbound नियम लिखना जो apt, npm, git और Claude API को फिर भी चलने दें, झंझट भरा काम है जो चुपचाप टूटता है। इसके बजाय सीमा को सैंडबॉक्स, कंटेनर या मशीन के स्तर पर चुनें, जहाँ एक डोमेन allow सूची या एक ख़ाली मशीन वही काम साफ़-सुथरे ढंग से कर देती है।

अगर आप Claude Code चलाने के बजाय API पर अपना एजेंट बना रहे हैं, तो यही सोच ज्यों की त्यों लागू होती है। VPS पर Claude से AI एजेंट बनाना उस रास्ते को कवर करता है, और उस एजेंट को भी वही समर्पित यूज़र और वही सीमित दायरे के टोकन चाहिए, उसी डिस्पोज़ेबल मशीन पर।

पहले मशीन को हार्डन करें

आप जो भी सीढ़ी चुनें, एजेंट के आने से पहले मशीन को ख़ुद भी बुनियादी चीज़ें चाहिए: सिर्फ़ SSH कुंजियाँ, कोई root लॉगिन नहीं, डिफ़ॉल्ट रूप से सब कुछ रोकने वाला फ़ायरवॉल, और अपने-आप लगने वाले सुरक्षा अपडेट। अपनी चेकलिस्ट यहाँ बनाएँ और एक बार पूरी निपटा लें:

FAQ

क्या सर्वर पर --dangerously-skip-permissions इस्तेमाल करना सुरक्षित है?

अकेले नहीं। यह फ़्लैग हर मंज़ूरी प्रॉम्प्ट हटा देता है, इसलिए पहली ग़लत कमांड उसी पल चल जाती है जिस पल मॉडल उसे बनाता है। यह सौदा तभी वाजिब ठहरता है जब नुक़सान का दायरा घिरा हो: कम से कम एक समर्पित, बिना विशेषाधिकार वाला यूज़र, और सचमुच बिना निगरानी वाले काम के लिए एक कंटेनर या एक डिस्पोज़ेबल VPS जिस पर एक प्रोजेक्ट और एक सीमित दायरे वाला टोकन ही हो। ऐसी मशीन पर इसे कभी इस्तेमाल न करें जिस पर प्रोडक्शन क्रेडेंशियल हों या ऐसा डेटा हो जिसे आप खो नहीं सकते।

क्या Claude Code में सैंडबॉक्स होता है?

हाँ। Claude Code शेल कमांडों के लिए एक बिल्ट-इन सैंडबॉक्स साथ लाता है, जो /sandbox कमांड से खुलता है। वह Linux पर bubblewrap और macOS पर Seatbelt इस्तेमाल करता है, लिखने को प्रोजेक्ट डायरेक्टरी तक सीमित करता है, और नेटवर्क पहुँच को ऐसे प्रॉक्सी से गुज़ारता है जो सिर्फ़ मंज़ूर किए गए डोमेन जाने देता है। उसका auto-allow मोड सैंडबॉक्स वाली कमांड बिना प्रॉम्प्ट के चलाता है, इसलिए वह skip फ़्लैग की तरह ही टोका-टोकी घटाता है, पर सीमा OS से लागू रहती है। यह पूरा अलगाव नहीं है, इसलिए बिना निगरानी वाले रन के लिए इसके साथ एक समर्पित यूज़र या एक समर्पित मशीन भी रखें।

skip फ़्लैग root के तौर पर चलने से क्यों इनकार करता है?

क्योंकि बिना परमिशन प्रॉम्प्ट वाला root सिस्टम की किसी भी फ़ाइल और किसी भी सर्विस को बदल सकता है, इसलिए Linux और macOS पर root के तौर पर या sudo के तहत चलने पर Claude Code --dangerously-skip-permissions को रोक देता है। इसका इलाज इस जाँच से लड़ना नहीं है। एजेंट के लिए एक बिना विशेषाधिकार वाला यूज़र बनाएँ और उसे वहीं चलाएँ; अकाउंट की वह सीमा घेराबंदी की पहली और सबसे सस्ती परत है।

क्या Claude Code मेरी SSH कुंजियाँ और .env फ़ाइलें पढ़ सकता है?

वह वह सब पढ़ सकता है जो उसका यूज़र पढ़ सकता है, और सैंडबॉक्स की डिफ़ॉल्ट पॉलिसी भी क्रेडेंशियल रास्तों को पढ़ने देती है, जब तक आप उन पर deny न लगा दें। इसलिए एजेंट को उसके अपने यूज़र के तौर पर चलाएँ, अपनी होम डायरेक्टरी mode 750 या उससे कसी हुई रखें, सैंडबॉक्स सेटिंग्स में क्रेडेंशियल रास्तों पर deny लगाएँ, और प्रोडक्शन सीक्रेट मशीन पर रखें ही नहीं। जो सीक्रेट मशीन पर कभी था ही नहीं, उसे न पढ़ा जा सकता है, न लीक किया जा सकता है।

बिना निगरानी Claude Code चलाने का सबसे सुरक्षित तरीक़ा क्या है?

एक सस्ता, सिर्फ़ एजेंट के काम के लिए रखा गया समर्पित VPS: दस मिनट में हार्डन किया हुआ, साफ़ हालत में snapshot लिया हुआ, जिस पर Claude Code बिना विशेषाधिकार वाले यूज़र के तौर पर और सैंडबॉक्स चालू रखकर चलता है। API कुंजी mode 600 वाली फ़ाइल में रहती है, git पहुँच के लिए प्रति-रिपॉज़िटरी deploy key होती है, और सारा काम उन branch पर होता है जिन्हें आप merge से पहले देखते हैं। कोई रन बिगड़े, तो आप एक टोकन रद्द करते हैं और snapshot वापस ले आते हैं, और आपकी बाक़ी किसी चीज़ पर असर नहीं पड़ता।