Coding agents के लिए disposable VM का उपयोग कैसे करें

डिस्पोजेबल VM आपके लैपटॉप से बेहतर क्यों है

किसी कोडिंग एजेंट को डिस्पोजेबल VM देने पर सबसे बुरा यह हो सकता है कि वह ऐसी मशीन को नष्ट कर दे जिसे आप दस मिनट में फिर से बना सकते हैं। एजेंट को अभी भी root एक्सेस मिलता है, वह पैकेज इंस्टॉल करता है और बिना हर कदम पर अनुमति मांगे टेस्ट सूट चलाता है। अंतर केवल इस बात का है कि नुकसान कहाँ होता है। लैपटॉप पर, एजेंट आपके SSH keys, ब्राउज़र प्रोफाइल, .env फाइलों और आपके द्वारा क्लोन की गई हर दूसरी रिपॉजिटरी के साथ होम डायरेक्टरी साझा करता है। एक थ्रोअवे सर्वर पर, उसके पास केवल एक शेल और एक चेकआउट होता है, और वहां लेने लायक कुछ भी नहीं होता।

यही पूरा तर्क है, और यह संभावना के बजाय विषमता (asymmetry) के बारे में है। एक सावधान लैपटॉप पर एक सावधान एजेंट लगभग हर बार ठीक काम करता है। जिस एक बार यह नहीं होता, उस समय नुकसान केवल एक खराब कमिट नहीं होता। यदि आपके पास बैकअप है, तो यह उससे रिस्टोर करने की नौबत होती है।

बहस करने से पहले blast radius को परिभाषित करें

Blast radius का अर्थ है उन चीजों का समूह जिन तक कोई process पहुँच सकती है। आपके सामान्य user के रूप में आपके सामान्य machine पर चल रहे agent के लिए, यह दायरा अधिकांश लोगों की कल्पना से कहीं अधिक बड़ा है।

इसमें ~/.ssh/id_ed25519 शामिल है, जो आमतौर पर unencrypted होता है, क्योंकि आप passphrase टाइप करते-करते थक चुके होते हैं। इसमें ~/.aws/credentials और ~/.config/gh/hosts.yml शामिल हैं, जो design के अनुसार plain text में होते हैं। इसमें ~/code के अंतर्गत आने वाली हर sibling repository शामिल है, जिसमें वे भी शामिल हैं जिनमें local env file में production connection strings मौजूद हैं। इसमें आपकी shell history भी शामिल है, जिसमें वे tokens होते हैं जिन्हें आपने कभी paste किया था। इसमें वह network भी शामिल है जिस पर आपका laptop जुड़ा है, जो अक्सर एक home या office network होता है जिस पर unauthenticated services चल रही होती हैं।

इसके लिए किसी malicious agent की आवश्यकता नहीं है। इसके लिए बस एक आत्मविश्वास के साथ गलत चलाया गया command काफी है। एक unset variable के साथ rm -rf जो / में expand हो जाता है, गलत directory में एक git clean -xfd, एक docker system prune -af --volumes जो आपके local database को भी साथ ले जाता है, या home directory पर एक सहायक chmod -R 777। Agents को उसी internet पर train किया जाता है जिसने बाकी सभी को ये commands सिखाए हैं।

जो mechanism आपको बचाता है, वह agent का निर्णय नहीं है। वह यह है कि जिस machine पर नुकसान हो रहा है, वह ऐसी machine है जिसे आप खोने के लिए तैयार थे।

लागत का गणित उबाऊ है, और यही इसका मुख्य उद्देश्य है

एक छोटा VPS हर महीने कुछ डॉलर का खर्च लाता है। एक developer laptop को रिकवर करने में पूरा दिन लग जाता है, और यह तब है जब सब कुछ ठीक रहे, यानी आपको तुरंत पता चल जाए और आपके पास backup मौजूद हो।

इसे अपने आंकड़ों के साथ समझें। अपनी प्रति घंटा दर (hourly rate) लें, और उसे उन घंटों से गुणा करें जो एक operating system को reinstall करने, home directory को restore करने, SSH key को rotate करने, personal access token को rotate करने और बीस repositories को फिर से clone करने में लगेंगे। इसकी तुलना अपने provider द्वारा बेचे जाने वाले सबसे छोटे सर्वर के 12 महीनों के खर्च से करें। break-even बिंदु हर कुछ वर्षों में एक incident से भी कम पर आ जाता है, और उस incident का विनाशकारी होना भी जरूरी नहीं है। एक corrupted local environment के कारण बर्बाद हुई एक दोपहर ही पूरे साल का खर्च निकाल देती है।

इस गणित का दूसरा हिस्सा snapshots हैं। किसी जोखिम भरे काम को करने से पहले लिया गया snapshot एक बुरे परिणाम को "मेरी पूरी मेहनत वापस लाओ" से बदलकर "roll back करो और दूसरा तरीका आजमाओ" में बदल देता है। यह विकल्प उस laptop पर मौजूद नहीं होता जिस पर आप अभी टाइप कर रहे हैं, क्योंकि जब आप किसी मशीन का उपयोग अपने डेस्क के रूप में कर रहे होते हैं, तो आप उसका snapshot नहीं ले सकते।

जुलाई 2026 तक की स्थिति

"एजेंट को कहाँ चलना चाहिए" इस प्रश्न के तीन ईमानदार उत्तर हैं, और वे दो मुख्य कारकों के बीच संतुलन बनाते हैं: बाउंड्री कितनी मजबूत है, और आप कितना सेटअप करने के लिए तैयार हैं।

एक लोकल micro VM। इस श्रेणी के टूल्स आपके हार्डवेयर पर एक वास्तविक वर्चुअल मशीन बूट करते हैं, उसमें आपकी रिपॉजिटरी माउंट करते हैं, और एजेंट को उसके अंदर root एक्सेस देते हैं। clawk इसका वर्तमान उदाहरण है, और इसका मुख्य उद्देश्य इस पोस्ट के थीसिस के समान है: कोडिंग एजेंटों को आपका लैपटॉप नहीं, बल्कि एक डिस्पोजेबल Linux VM दें। जुलाई 2026 तक यह Apple silicon पर macOS 14 और उसके बाद के वर्ज़न को टारगेट करता है, जिसमें Firecracker के माध्यम से प्रयोगात्मक Linux सपोर्ट शामिल है, और यह brew install clawkwork/tap/clawk के साथ इंस्टॉल होता है। सैंडबॉक्स बूट करने और एजेंट अटैच करने के लिए आप रिपॉजिटरी के अंदर clawk चलाते हैं, इसे रोकने के लिए clawk down, और इसे हटाने के लिए clawk destroy का उपयोग करते हैं। इसकी बाउंड्री एक हाइपरवाइजर है, जो कि मजबूत है। इसकी सीमा यह है कि VM उसी मशीन पर रहता है जिसे आप साथ लेकर चलते हैं, इसलिए यह आपकी मेमोरी के लिए प्रतिस्पर्धा करता है और लैपटॉप बंद करने पर यह भी रुक जाता है।

एक कंटेनर। Docker वह उत्तर है जो अधिकांश लोगों के पास पहले से ही इंस्टॉल है, और यह वास्तव में उपयोगी है।

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm बाहर निकलने पर कंटेनर को हटा देता है और --network none इसे बिल्कुल भी नेटवर्क नहीं देता है, जो कि बिल्ड या टेस्ट रन के लिए एक अच्छा डिफ़ॉल्ट है। यह स्पष्ट रहें कि यह क्या नहीं करता है: एक कंटेनर होस्ट कर्नेल साझा करता है, इसलिए कर्नेल बग बाहर निकलने का एक रास्ता है, और जैसे ही आप --privileged जोड़ते हैं या /var/run/docker.sock माउंट करते हैं ताकि एजेंट "Docker का उपयोग" कर सके, बाउंड्री समाप्त हो जाती है। Docker सॉकेट को कंटेनर में माउंट करना उस कंटेनर को होस्ट पर root एक्सेस देने के बराबर है।

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

VPS पैटर्न: एजेंट को अपना अलग यूजर दें

एक सुरक्षित (hardened) सर्वर से शुरुआत करें। नए VPS पर शुरुआती दस मिनट उन हिस्सों को कवर करते हैं जो एजेंट-विशिष्ट नहीं हैं: अपडेट, एक नॉन-रूट लॉगिन, केवल-की (key-only) SSH, और एक फायरवॉल।

इसके बाद, एक ऐसा अकाउंट बनाएं जो केवल एजेंट के लिए हो, ताकि उसके भीतर की गई कोई भी गलती सर्वर पर किसी और चीज को प्रभावित न कर सके।

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password का मतलब है कि अनुमान लगाने के लिए कोई पासवर्ड नहीं है, और आप इस अकाउंट तक sudo -u agent या SSH की (key) के माध्यम से पहुँचते हैं। ध्यान दें कि agent जानबूझकर sudo समूह में नहीं है। sudo वाले एजेंट के पास रूट एक्सेस होता है, और रूट किसी भी अन्य यूजर की फाइलें पढ़ सकता है, इसलिए जो अलगाव (separation) आपने अभी बनाया है वह केवल दिखावटी है। यदि एजेंट को वास्तव में पैकेज इंस्टॉल करने की आवश्यकता है, तो यह उसे एक अलग सर्वर देने का तर्क है, न कि साझा सर्वर पर उसे sudo देने का। सामान्य नियम VPS पर Linux यूजर्स के लिए न्यूनतम विशेषाधिकार (least privilege) में दिए गए हैं।

उस पर भरोसा करने से पहले सीमा (boundary) की जाँच करें। agent यूजर के रूप में, अपने स्वयं के अकाउंट की कोई फाइल पढ़ने का प्रयास करें:

sudo -u agent cat /home/you/.ssh/id_ed25519

आपको cat: /home/you/.ssh/id_ed25519: Permission denied दिखाई देना चाहिए। यदि आपको इसके बजाय की-मटेरियल (key material) दिखाई देता है, तो आपकी होम डायरेक्टरी का मोड 755 है और अलगाव अभी वास्तविक नहीं है। इसे sudo chmod 700 /home/you के साथ ठीक करें।

क्रेडेंशियल्स को मशीन से पूरी तरह दूर रखें

डिस्पोजेबल मशीन का उद्देश्य तब विफल हो जाता है यदि आप उस पर अपने प्रोडक्शन सीक्रेट्स कॉपी कर लेते हैं। नियम सरल है: उस बॉक्स पर ऐसी कोई भी चीज़ क्रेडेंशियल के रूप में नहीं होनी चाहिए जिसे आज दोपहर रोटेट करने में आपको कोई आपत्ति हो।

git के लिए, की (key) कॉपी करने के बजाय अपने SSH agent को फॉरवर्ड करें। प्राइवेट की आपके लैपटॉप पर ही रहती है और केवल सिग्नेचर रिक्वेस्ट ही कनेक्शन के माध्यम से जाती हैं।

ssh -A agent@203.0.113.10
ssh -T git@github.com

दूसरा कमांड Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. का उत्तर देना चाहिए। यह साबित करता है कि सर्वर पर कोई की-फाइल मौजूद न होने पर भी git push काम करेगा। इसके बाद बॉक्स पर ls -la ~/.ssh चलाएं और पुष्टि करें कि इसमें कोई प्राइवेट की नहीं है।

एजेंट फॉरवर्डिंग की एक वास्तविक चेतावनी है, इसलिए इसे स्पष्ट रूप से समझें: जब तक आप कनेक्टेड हैं, उस सर्वर पर रूट एक्सेस वाला कोई भी व्यक्ति आपकी ओर से ऑथेंटिकेट करने के लिए फॉरवर्ड किए गए सॉकेट का उपयोग कर सकता है। ऐसे सर्वर पर जिसका एकमात्र अन्य उपयोगकर्ता आप स्वयं हैं, यह एक स्वीकार्य समझौता है। एक शेयर्ड बॉक्स पर ऐसा नहीं है, और एक रिपॉजिटरी तक सीमित 'डिप्लॉय की' (deploy key) बेहतर विकल्प है। इन विकल्पों को SSH key management basics में कवर किया गया है।

API कीज़ के लिए, एजेंट को उसकी अपनी की दें जिसकी अपनी स्पेंडिंग लिमिट हो, जिसे agent उपयोगकर्ता के स्वामित्व वाली फाइल में मोड 600 पर स्टोर किया गया हो। जब मशीन को नष्ट किया जाए, तो उस की को रिवोक (revoke) कर दें, बजाय इसके कि यह सोचें कि क्या वह लीक हो गई है। प्रति की मॉडल खर्च को दृश्यमान रखना ही वह तरीका है जिससे AI agent cost control on a VPS में आंकड़े अनुमानित बने रहते हैं।

एजेंट नेटवर्क पर क्या एक्सेस कर सकता है, इसे सीमित करें

Filesystem isolation सुरक्षा सीमा का आधा हिस्सा है। दूसरा आधा हिस्सा egress है: यानी यह तय करना कि process किससे बात कर सकती है। Linux outbound traffic को उस user के आधार पर filter कर सकता है जिसने उसे बनाया है, जो इस पैटर्न के लिए बिल्कुल उपयुक्त है।

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

नियमों को क्रम में पढ़ा जाता है, इसलिए अंतिम REJECT उन सभी चीजों को रोक देता है जिन्हें पिछली पंक्तियों ने अनुमति नहीं दी थी। इसे agent के रूप में test करें:

sudo -u agent curl -sS -m 5 http://example.com

इसे curl: (7) Failed to connect to example.com port 80: Connection refused के साथ fail हो जाना चाहिए, क्योंकि reject rule कनेक्शन को लटकाने के बजाय तुरंत जवाब देता है। उसी host पर एक HTTPS request अभी भी सफल होनी चाहिए।

दो वास्तविक सीमाएँ हैं। पहली, ये नियम अगले reboot पर खो जाते हैं जब तक कि आप उन्हें sudo apt install -y iptables-persistent और फिर sudo netfilter-persistent save के साथ save न करें। दूसरी, यह ports और addresses को filter करता है, names को नहीं। port 443 की अनुमति देने वाला नियम इंटरनेट पर हर HTTPS host को अनुमति देता है, जो model API तक पहुँचने के लिए पर्याप्त है और pastebin तक पहुँचने के लिए भी। एक सही domain allow-list के लिए traffic को ऐसे proxy से गुजरना होगा जो requested hostname को पढ़ सके, जो कि अधिकांश single-developer setups की तुलना में अधिक जटिल प्रक्रिया है। केवल वही दावा करें जो आपके पास है: port-level egress control, एक ऐसी machine पर जिसे खोने के लिए आप तैयार थे।

कार्यों के बीच क्लीन स्टेट पर रीसेट करना

प्रत्येक कार्य के लिए क्लीन स्टेट (clean state) का होना एक ऐसा लाभ है जिसे अक्सर कम आंका जाता है। जिस एजेंट ने पिछले टिकट पर तीन घंटे बिताए, उसने पीछे इंस्टॉल किए गए पैकेज, आधे-अधूरे लागू किए गए माइग्रेशन, एक पुराना node_modules, और एक ऐसा git वर्किंग ट्री छोड़ दिया जिसके बदलावों की किसी ने समीक्षा नहीं की। अगला कार्य इन सबको विरासत में ले लेता है, और आप अपना समीक्षा बजट यह पता लगाने में खर्च करते हैं कि कौन सी गंदगी किस रन (run) की है। एक सीमित दायरा रखने वाला एजेंट पहली बार में ही कम चीजें पीछे छोड़ता है, इसलिए एक डिस्पोजेबल मशीन को ऐसी स्किल जो एजेंट को सबसे छोटे कार्यशील बदलाव की ओर ले जाती है के साथ जोड़ना, diff और बची हुई स्टेट दोनों को इतना छोटा रखता है कि उनकी समीक्षा की जा सके।

इसका सस्ता संस्करण प्रत्येक कार्य के लिए एक फ्रेश चेकआउट (fresh checkout) है।

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

इसका अधिक प्रभावी संस्करण एक प्रोवाइडर स्नैपशॉट है, जिसे मशीन सेटअप होने के तुरंत बाद और किसी भी एजेंट के उसे छूने से पहले लिया जाता है। उस स्नैपशॉट को रिस्टोर करने से पूरा सिस्टम, जिसमें पैकेज भी शामिल हैं, एक ज्ञात स्टेट में वापस आ जाता है। अधिकांश प्रोवाइडर इसे कंट्रोल पैनल में या API के माध्यम से उपलब्ध कराते हैं, न कि बॉक्स पर किसी कमांड के रूप में, इसलिए सटीक चरण आपके प्रोवाइडर के अनुसार होंगे। अनुशासन यह है कि स्नैपशॉट तब लें जब मशीन अभी भी सामान्य (boring) हो।

ऐसी किसी भी चीज़ को डिस्पोजेबल मशीन पर न रखें जिसकी आपको परवाह है, जिसका मुख्य अर्थ है शाखाओं (branches) को स्थानीय रूप से जमा करने के बजाय उन्हें पुश करना। यदि बॉक्स में वास्तव में कुछ ऐसा रह जाता है जिसे आप खोना नहीं चाहते, तो VPS पर restic बैकअप के साथ उसका उचित बैकअप लें। एक मशीन जिसे आप नष्ट कर सकते हैं, तभी उपयोगी है जब उसे नष्ट करना वास्तव में सामान्य बात हो।

यदि आप कई सर्वरों के लिए भुगतान किए बिना कई अलग-थलग वातावरण चाहते हैं, तो एक बड़ा VPS सीधे गेस्ट VM को होस्ट कर सकता है। VPS पर नेस्टेड वर्चुअलाइजेशन यह बताता है कि यह कैसे काम करता है, जिसमें यह भी शामिल है कि यह कैसे जांचें कि आपका प्रोवाइडर इसकी अनुमति देता है या नहीं। आइसोलेशन यहाँ दोनों तरफ काम करता है, और यदि आप एक ही बॉक्स पर दो एजेंटों को एक-दूसरे से अलग रहने के बजाय समन्वय (coordinate) करने देना चाहते हैं, तो एक Claude Code सेशन सीधे दूसरे को टेक्स्ट भेज सकता है, बजाय इसके कि हर हैंडऑफ को आपके माध्यम से रूट किया जाए।

जब लैपटॉप का सावधानीपूर्वक उपयोग करना पूरी तरह सुरक्षित हो

इस बारे में ईमानदार रहें, क्योंकि आइसोलेशन को बढ़ा-चढ़ाकर बताने से लोग आपकी बात सुनना बंद कर देते हैं।

यदि आप हर कमांड को चलाने से पहले उसकी समीक्षा कर रहे हैं, तो लैपटॉप का उपयोग करना ठीक है। परमिशन प्रॉम्प्ट एक वास्तविक नियंत्रण है, और सर्वर पर सुरक्षित रूप से Claude Code चलाना यह बताता है कि इसका प्रत्येक स्तर वास्तव में क्या रोकता है। यदि आपका काम एक सिंगल रिपॉजिटरी है और मशीन पर कहीं भी प्रोडक्शन क्रेडेंशियल्स नहीं हैं, तो नुकसान का दायरा पहले से ही सीमित है। यदि आपके एजेंट सेशन छोटे और पर्यवेक्षित (supervised) हैं, तो जोखिम की अवधि भी कम होती है।

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

यह निर्णय वास्तव में इस बारे में नहीं है कि आप मॉडल पर कितना भरोसा करते हैं। यह इस बारे में है कि जब मॉडल गलत होता है, तो उसके साथ क्या मौजूद है।

FAQ

क्या कोडिंग एजेंट के लिए कंटेनर आइसोलेशन पर्याप्त है?

अधिकांश कार्यों के लिए हाँ, लेकिन दो शर्तों के साथ। कंटेनर को --privileged के साथ नहीं चलना चाहिए, और इसमें /var/run/docker.sock माउंट नहीं होना चाहिए, क्योंकि ये दोनों ही प्रक्रिया को होस्ट पर root एक्सेस का रास्ता दे सकते हैं। कंटेनर होस्ट kernel साझा करता है, इसलिए इसकी सीमा virtual machine की तुलना में कमजोर होती है। यदि एजेंट इंटरनेट से लिया गया अविश्वसनीय कोड चला रहा है, तो एक वास्तविक VM या अलग सर्वर का उपयोग करना बेहतर है।

क्या एजेंट को सर्वर पर sudo की आवश्यकता है?

नहीं, और इसे sudo देना आपके द्वारा बनाई गई आइसोलेशन को खत्म कर देता है, क्योंकि root सर्वर पर मौजूद हर दूसरे अकाउंट को पढ़ सकता है। एजेंट यूजर को बिना sudo के बनाएं और उसे केवल उसके कार्य निर्देशिका (work directory) में लिखने की अनुमति दें। यदि कार्य के लिए वास्तव में पैकेज इंस्टॉलेशन की आवश्यकता है, तो एजेंट को एक पूरी मशीन दें, न कि साझा मशीन पर root एक्सेस।

मैं अपनी SSH key को बॉक्स पर रखे बिना एजेंट को git पर पुश करने की अनुमति कैसे दूँ?

कनेक्ट करते समय अपने SSH agent को ssh -A के साथ फॉरवर्ड करें। सिग्नेचर अनुरोध कनेक्शन के माध्यम से जाते हैं जबकि private key आपके लैपटॉप पर ही रहती है, इसलिए ssh -T git@github.com ऑथेंटिकेट करता है और git push बिना सर्वर पर private key रखे काम करता है। सावधानी यह है कि जब आप कनेक्टेड होते हैं, तो उस सर्वर पर root फॉरवर्ड किए गए सॉकेट का उपयोग कर सकता है, इसलिए किसी भी ऐसी मशीन पर जिसे आप अन्य लोगों के साथ साझा करते हैं, repository-scoped deploy key का उपयोग करें।

एजेंट को किस आकार के VPS की आवश्यकता होती है?

एजेंट का काम मुख्य रूप से फाइलें एडिट करना, बिल्ड चलाना और टेस्ट चलाना है, इसलिए मशीन का आकार मॉडल के बजाय बिल्ड के अनुसार चुनें। एक होस्ट किया गया मॉडल प्रदाता के हार्डवेयर पर चलता है, जो नेटवर्क ट्रैफिक जोड़ता है लेकिन स्थानीय लोड लगभग शून्य होता है। स्क्रिप्टिंग कार्य के लिए 2 GB RAM से शुरुआत करें और यदि रिपॉजिटरी कंटेनर बनाती है या कुछ महत्वपूर्ण कंपाइल करती है, तो 8 GB तक बढ़ें।

मुझे मशीन को कितनी बार नष्ट करके फिर से बनाना चाहिए?

जब सिस्टम की स्थिति को समझा न जा सके, तब उसे फिर से बनाएं, और कम से कम तब तो जरूर जब बॉक्स पर मौजूद कोई क्रेडेंशियल एक्सपोज हो गया हो। कार्यों के बीच एक फ्रेश चेकआउट दैनिक बदलावों (drift) को संभाल लेता है, और पहले एजेंट रन से पहले लिया गया स्नैपशॉट आपको वापस जाने के लिए एक क्लीन सिस्टम इमेज देता है। यदि फिर से बनाना महंगा लगता है, तो यह संकेत है कि कोई महत्वपूर्ण चीज उस मशीन पर मौजूद है जिसे आपने डिस्पोजेबल कहा था।