AI coding agent کے لیے disposable VM کیوں دیں؟

آپ کے laptop سے عارضی VM کیوں زیادہ محفوظ انتخاب ہے

کسی coding agent کو ایسی عارضی VM دیں جسے دوبارہ بنایا جا سکتا ہو، تو وہ زیادہ سے زیادہ ایسی machine تباہ کر سکتا ہے جسے آپ 10 منٹ میں دوبارہ بنا لیں۔ Agent کو پھر بھی root access حاصل رہتا ہے، وہ packages install کر سکتا ہے، اور ہر مرحلے کی اجازت مانگے بغیر test suite چلا سکتا ہے۔ فرق صرف یہ ہے کہ نقصان کہاں ہوتا ہے۔ laptop پر agent کا home directory آپ کی SSH keys، browser profile، آپ کی .env files، اور ہر اس repository کے ساتھ مشترک ہوتا ہے جسے آپ نے کبھی clone کیا ہے۔ عارضی server پر اس کے پاس shell، checkout، اور اس کے علاوہ چرانے کے قابل کوئی اہم چیز نہیں ہوتی۔

بات کا خلاصہ یہی ہے، اور یہ امکان کے بجائے عدم توازن کا معاملہ ہے۔ محتاط laptop پر محتاط agent تقریباً ہر بار ٹھیک رہتا ہے۔ لیکن جس ایک بار ایسا نہ ہو، اس کی قیمت صرف ایک خراب commit نہیں ہوتی۔ اگر backup موجود ہو تو backup سے restore کرنا پڑتا ہے۔

نقصان کے دائرے پر بحث سے پہلے اس کی حد متعین کریں

نقصان کا دائرہ ان تمام چیزوں کا مجموعہ ہے جن تک کوئی process رسائی حاصل کر سکتا ہے۔ آپ کی عام مشین پر عام user کے طور پر چلنے والے agent کے لیے یہ مجموعہ اکثر لوگوں کے تصور سے کہیں بڑا ہوتا ہے۔

اس میں ~/.ssh/id_ed25519 شامل ہے، جو عموماً unencrypted ہوتا ہے، کیونکہ آپ passphrase بار بار لکھتے لکھتے اکتا گئے تھے۔ اس میں ~/.aws/credentials اور ~/.config/gh/hosts.yml شامل ہیں، جو design کے لحاظ سے plain text ہوتے ہیں۔ اس میں ~/code کے اندر موجود ہر sibling repository شامل ہے، جن میں وہ repositories بھی شامل ہیں جن کی local env file میں production connection strings موجود ہیں۔ اس میں آپ کی shell history بھی شامل ہے، جس میں وہ tokens محفوظ ہیں جو آپ نے کبھی ایک بار paste کیے تھے۔ اس میں وہ network بھی شامل ہے جس سے آپ کا laptop منسلک ہے؛ یہ اکثر home یا office network ہوتا ہے جس پر unauthenticated services چل رہی ہوتی ہیں۔

اس کے لیے malicious agent درکار نہیں ہوتا۔ صرف ایک پراعتماد مگر غلط command کافی ہے۔ BUILD_DIR کے unset ہونے کی صورت میں rm -rf "$BUILD_DIR"/*، جو /* میں expand ہو جاتا ہے اور GNU rm کے اس default refusal سے بچ نکلتا ہے کہ وہ خود / کو delete نہ کرے؛ غلط directory میں موجود git clean -xfd؛ ایسا docker system prune -af --volumes جو آپ کا local database بھی حذف کر دے؛ یا home directory پر کیا گیا مددگار chmod -R 777۔ Agents اسی internet کے data پر trained ہوتے ہیں جس نے یہ commands باقی سب کو سکھائے ہیں۔

آپ کو محفوظ رکھنے والا mechanism agent کا فیصلہ نہیں ہے۔ اصل تحفظ یہ ہے کہ نقصان اٹھانے والی machine ایسی ہے جسے کھونے پر آپ آمادہ تھے۔

لاگت کا حساب اکتاہٹ بھرا ہے، اور یہی اس کا مقصد ہے

ایک چھوٹے VPS کی ماہانہ لاگت چند ڈالر ہوتی ہے۔ ڈویلپر کے laptop کو بحال کرنے میں ایک دن لگ سکتا ہے۔ یہ اس وقت بہتر صورت ہے جب آپ مسئلہ فوراً محسوس کر لیں اور آپ کے پاس backup موجود ہو۔

اپنے اعداد و شمار سے حساب لگائیں۔ اپنی فی گھنٹہ شرح لیں اور اسے ان گھنٹوں سے ضرب دیں جو operating system دوبارہ install کرنے، home directory بحال کرنے، SSH key تبدیل کرنے، personal access token تبدیل کرنے، اور 20 repositories دوبارہ clone کرنے میں لگیں گے۔ اس رقم کا موازنہ آپ کے provider کے فراہم کردہ سب سے چھوٹے server کے 12 ماہ کے خرچ سے کریں۔ break-even کئی سالوں میں ایک incident سے بھی کم پر آ جاتا ہے۔ اس کے لیے incident کا تباہ کن ہونا ضروری نہیں۔ مقامی environment کو خراب ہونے کی وجہ سے ضائع ہونے والی ایک دوپہر بھی پورے سال کی لاگت پوری کر دیتی ہے۔

حساب کا دوسرا حصہ snapshots ہیں۔ کسی خطرناک run سے پہلے snapshot لینے سے خراب نتیجہ "میری پوری زندگی بحال کرو" سے بدل کر "واپس پچھلی حالت پر جاؤ اور مختلف prompt آزماؤ" بن جاتا ہے۔ جس laptop پر آپ یہ متن لکھ رہے ہیں، اس میں یہ اختیار موجود نہیں، کیونکہ جب آپ اسے اپنے کام کی میز کے طور پر استعمال کر رہے ہوں تو اس کا snapshot نہیں لے سکتے۔

اکتوبر 2026 تک صورتِ حال

اس سوال کہ "ایجنٹ کہاں چلنا چاہیے"، کے تین واضح جواب ہیں۔ ان میں وہی دو چیزیں باہم متوازن ہوتی ہیں: boundary کتنی مضبوط ہے، اور آپ کتنا setup برداشت کر سکتے ہیں۔

ایک مقامی micro VM۔ اس زمرے کے tools آپ کے اپنے hardware پر ایک حقیقی virtual machine boot کرتے ہیں، اس میں آپ کی repository mount کرتے ہیں، اور ایجنٹ کو اس کے اندر root access دیتے ہیں۔ clawk اس وقت کی مثال ہے، اور اس کا بنیادی مؤقف بالکل اس پوسٹ کے thesis جیسا ہے: coding agents کو اپنے laptop کے بجائے ایک عارضی Linux VM دیں۔ اکتوبر 2026 تک یہ Apple silicon والے macOS 14 اور بعد کے versions کو target کرتا ہے، جبکہ Firecracker کے ذریعے experimental Linux support بھی فراہم کرتا ہے، اور brew install clawkwork/tap/clawk سے install ہوتا ہے۔ repository کے اندر clawk چلانے سے sandbox boot ہوتا ہے اور ایجنٹ attach ہوتا ہے، clawk down سے اسے stop کیا جاتا ہے، اور clawk destroy سے remove کیا جاتا ہے۔ boundary hypervisor ہے، اس لیے مضبوط ہے۔ حد یہ ہے کہ VM اسی machine پر چلتی ہے جسے آپ ساتھ لے کر چلتے ہیں، اس لیے یہ آپ کی memory کے لیے مقابلہ کرتی ہے اور lid بند کرتے ہی رک جاتی ہے۔

ایک container۔ Docker وہ جواب ہے جو زیادہ تر لوگوں کے پاس پہلے ہی installed ہوتا ہے، اور یہ واقعی مفید ہے۔

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

--rm exit پر container کو discard کر دیتا ہے، جبکہ --network none اسے network access بالکل نہیں دیتا۔ build یا test run کے لیے یہ ایک اچھا default ہے۔ یہ واضح رہنا چاہیے کہ یہ کیا نہیں کرتا: container host kernel share کرتا ہے، اس لیے kernel bug کے ذریعے boundary سے باہر نکلا جا سکتا ہے، اور جیسے ہی آپ --privileged شامل کرتے ہیں یا /var/run/docker.sock mount کرتے ہیں تاکہ ایجنٹ "Docker استعمال کر سکے"، boundary ختم ہو جاتی ہے۔ Docker socket کو container میں mount کرنا اس container کو host پر root access دینے کے برابر ہے۔

ایک سادہ VPS جسے آپ دوبارہ build کر سکیں۔ اس میں کسی نئے tool کی ضرورت نہیں، حقیقی kernel boundary ملتی ہے، provider snapshots دستیاب ہوتے ہیں، اور آپ کے laptop کو بند کرنے کے بعد بھی یہ چلتا رہتا ہے۔ اس guide کا باقی حصہ اسی pattern کی وضاحت کرتا ہے۔ طویل agent runs کے لیے بھی یہی طریقہ برقرار رہتا ہے، کیونکہ چار گھنٹے لینے والے job کو اس بات سے فرق نہیں پڑتا کہ آپ گھر چلے گئے ہیں۔

VPS کا طریقہ: agent کو اپنا user دیں

ایک hardened box سے شروع کریں۔ نئے VPS کے پہلے دس منٹ میں وہ اقدامات شامل ہیں جو agent کے لیے مخصوص نہیں ہیں: updates، non-root login، صرف key کے ذریعے SSH، اور firewall۔

پھر ایسا account بنائیں جو صرف agent کے لیے موجود ہو، تاکہ اس کے اندر ہونے والی کسی غلطی سے server پر کوئی دوسری چیز متاثر نہ ہو۔

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 کا مطلب ہے کہ guess کرنے کے لیے کوئی password موجود نہیں، اور آپ sudo -u agent یا SSH key کے ذریعے اس account تک پہنچتے ہیں۔ یاد رکھیں کہ agent کو جان بوجھ کر sudo group میں شامل نہیں کیا گیا۔ جس agent کے پاس sudo ہو، اسے root حاصل ہوتا ہے، اور root ہر دوسرے user کی files پڑھ سکتا ہے۔ اس صورت میں ابھی بنائی گئی علیحدگی محض ظاہری رہ جاتی ہے۔ اگر agent کو واقعی packages install کرنے کی ضرورت ہے، تو یہ اس کے لیے مکمل server مختص کرنے کی دلیل ہے، نہ کہ shared server پر اسے sudo دینے کی۔ عمومی قواعد VPS پر Linux users کے لیے کم سے کم مراعات میں بیان کیے گئے ہیں۔

اس boundary پر اعتماد کرنے سے پہلے اسے check کریں۔ agent user کے طور پر اپنے account کی home directory کی فہرست دکھانے کی کوشش کریں:

sudo -u agent ls /home/you

آپ کو ls: cannot open directory '/home/you': Permission denied نظر آنا چاہیے۔ اگر اس کے بجائے files کی فہرست نظر آئے تو آپ کی home directory دوسرے users کے لیے readable ہے، اور agent اس میں موجود ہر ایسی چیز پڑھ سکتا ہے جسے الگ سے محدود نہ کیا گیا ہو، مثلاً world-readable .env file۔ اسے sudo chmod 700 /home/you کے ذریعے درست کریں۔ آپ کی private SSH key اس test کے تحفظ میں شامل نہیں ہے: ssh ایسی private key file کو نظر انداز کرتا ہے جس تک دوسرے users رسائی حاصل کر سکتے ہوں، اس لیے جو key واقعی آپ کے لیے کام کرتی ہے وہ پہلے ہی agent کے لیے unreadable ہے، خواہ آپ کی home directory کا mode کچھ بھی ہو۔

اسناد کو پوری طرح مشین سے باہر رکھیں

اگر آپ اپنی production secrets اس مشین پر copy کر دیں تو disposable machine کا مقصد ہی ختم ہو جاتا ہے۔ اصول سادہ ہے: اس machine پر ایسی کوئی credential نہیں ہونی چاہیے جسے آپ آج دوپہر rotate کرنا پسند نہ کریں۔

git کے لیے key copy کرنے کے بجائے اپنا SSH agent forward کریں۔ private key آپ کے laptop پر رہتی ہے، اور connection کے ذریعے صرف signature requests گزرتی ہیں۔

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

دوسرے command کا جواب Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. ہونا چاہیے۔ اس سے ثابت ہوتا ہے کہ git push server پر key file موجود نہ ہونے کے باوجود کام کرے گا۔ اس کے بعد machine پر ls -la ~/.ssh چلائیں اور تصدیق کریں کہ اس میں کوئی private key موجود نہیں ہے۔

Agent forwarding میں ایک حقیقی caveat ہے، اس لیے اسے واضح طور پر بیان کریں: connection برقرار رہنے کے دوران، اس server پر root رکھنے والا کوئی بھی شخص forwarded socket استعمال کرکے آپ کی حیثیت سے authenticate کر سکتا ہے۔ اگر اس server کا واحد دوسرا user آپ خود ہیں تو یہ قابل قبول trade-off ہے۔ Shared box پر ایسا نہیں ہے، اور صرف ایک repository تک محدود deploy key بہتر حل ہے۔ اختیارات SSH key management کی بنیادی باتیں میں بیان کیے گئے ہیں۔

API keys کے لیے agent کو اپنی الگ key دیں، جس کی اپنی spending limit ہو، اور اسے ایسی file میں محفوظ کریں جس کا مالک agent user ہو اور mode 600 ہو۔ Machine destroy ہونے پر یہ key revoke کر دیں، بجائے اس کے کہ آپ یہ سوچتے رہیں کہ آیا یہ leak ہوئی تھی۔ ہر key کے لحاظ سے model spend کو نمایاں رکھنا ہی وہ طریقہ ہے جس سے VPS پر AI agent کے اخراجات کا کنٹرول میں موجود اعداد قابل پیش گوئی رہتے ہیں۔

ایجنٹ کی نیٹ ورک تک رسائی محدود کریں

فائل سسٹم کی isolation حد کا صرف نصف حصہ ہے۔ دوسرا نصف egress ہے: process کو کن endpoints سے رابطہ کرنے کی اجازت ہے۔ Linux اس process کو بنانے والے user کی بنیاد پر outbound traffic 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

Rules کو اسی ترتیب سے پڑھا جاتا ہے، اس لیے آخری REJECT ان تمام connections کو پکڑ لیتا ہے جن کی پہلے والی lines نے اجازت نہیں دی۔ اسے agent کے طور پر test کریں:

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

یہ فوراً curl: (7) Failed to connect to example.com error کے ساتھ fail ہونا چاہیے۔ اس کے بعد کا متن آپ کے curl version کے مطابق مختلف ہو سکتا ہے، کیونکہ reject rule connection کو hang ہونے دینے کے بجائے فوراً جواب دیتا ہے۔ اسی host کو HTTPS request پھر بھی کامیاب ہونی چاہیے۔

دو اہم حدود ذہن میں رکھیں۔ پہلی، اگلے reboot پر یہ rules ختم ہو جاتے ہیں، جب تک کہ آپ انہیں sudo apt install -y iptables-persistent اور پھر sudo netfilter-persistent save کے ذریعے save نہ کریں۔ دوسری، یہ filtering ports اور addresses پر ہوتی ہے، names پر نہیں۔ port 443 کی اجازت internet پر موجود ہر HTTPS host تک رسائی دیتی ہے۔ اس سے model API تک بھی پہنچا جا سکتا ہے اور pastebin تک بھی۔ حقیقی domain allow-list کے لیے traffic کو ایسے proxy سے گزارنا ہوگا جو requested hostname پڑھ سکے۔ یہ زیادہ machinery ہے، جس کی اکثر single-developer setups کو ضرورت نہیں ہوتی۔ صرف اتنا دعویٰ کریں جتنا آپ نے واقعی نافذ کیا ہے: port-level egress control، ایسی machine پر جسے کھونے کے لیے آپ تیار تھے۔

کاموں کے درمیان صاف حالت بحال کریں

ہر کام کے لیے صاف حالت ایک کم توجہی حاصل کرنے والا فائدہ ہے۔ ایک agent نے پچھلے ticket پر تین گھنٹے کام کیا، لیکن installed packages، ادھوری migrations، ایک پرانا node_modules، اور ایسا git working tree چھوڑ دیا جس میں کسی نے تبدیلیوں کا جائزہ نہیں لیا تھا۔ اگلا کام یہ سب کچھ inherited حالت میں حاصل کرتا ہے، اور آپ اپنا review budget اس بات کا تعین کرنے میں صرف کرتے ہیں کہ کون سی خرابی کس run سے متعلق ہے۔ محدود دائرے والا agent ابتدا ہی میں کم چیزیں پیچھے چھوڑتا ہے۔ اس لیے disposable machine کو ایسی skill کے ساتھ جوڑنا جو agent کو کام کرنے والی سب سے چھوٹی تبدیلی کی طرف لے جائے diff اور باقی ماندہ state، دونوں کو جائزے کے لیے کافی حد تک محدود رکھتا ہے۔

اس کا آسان طریقہ ہر کام کے لیے fresh checkout ہے۔

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

زیادہ مضبوط طریقہ provider snapshot ہے، جو machine set up کرنے کے فوراً بعد اور کسی agent کے اسے استعمال کرنے سے پہلے صرف ایک بار لیا جائے۔ اس snapshot کو restore کرنے سے packages سمیت پورا system ایک معلوم حالت میں واپس آ جاتا ہے۔ زیادہ تر providers یہ سہولت box پر command کے بجائے control panel یا API کے ذریعے دیتے ہیں، اس لیے درست مراحل آپ کے provider پر منحصر ہیں۔ اصول یہ ہے کہ snapshot اس وقت لیا جائے جب machine ابھی غیر تبدیل شدہ ہو۔

جس چیز کی آپ کو ضرورت ہے اسے disposable machine سے باہر رکھیں۔ عموماً اس کا مطلب branches کو مقامی طور پر جمع کرنے کے بجائے push کرنا ہے۔ اگر box میں کوئی ایسی چیز رہ جائے جس کے ضائع ہونے پر آپ کو افسوس ہو، تو VPS پر restic backups کے ذریعے اس کا مناسب backup لیں۔ ایسی machine جسے آپ destroy کر سکتے ہیں، تبھی مفید ہے جب اسے destroy کرنا واقعی کسی پیچیدگی کے بغیر ہو۔

اگر آپ متعدد servers کے لیے ادائیگی کیے بغیر کئی isolated environments چاہتے ہیں، تو ایک بڑا VPS براہ راست guest VMs host کر سکتا ہے۔ VPS پر nested virtualisation میں اس کا طریقہ بیان کیا گیا ہے، جس میں یہ جانچنا بھی شامل ہے کہ آیا آپ کا provider اسے اجازت دیتا ہے۔ یہاں isolation کے دونوں پہلو ہیں۔ اگر آپ ایک ہی box پر دو agents کو ایک دوسرے سے الگ رہنے کے بجائے باہمی coordination کرنا چاہتے ہیں، تو ایک Claude Code session براہ راست دوسرے کو text بھیج سکتا ہے اور ہر handoff کو اپنے ذریعے route کرنے کی ضرورت نہیں رہتی۔

جب احتیاط کے ساتھ laptop واقعی کافی ہوتا ہے

اس بارے میں دیانت داری ضروری ہے، کیونکہ isolation کو بڑھا چڑھا کر پیش کرنے سے لوگ سننا چھوڑ دیتے ہیں۔

اگر آپ ہر command کے چلنے سے پہلے اس کا جائزہ لیتے ہیں تو laptop کافی ہے۔ permission prompt ایک حقیقی control ہے، اور server پر Claude Code محفوظ طریقے سے چلانا واضح کرتا ہے کہ اس کی ہر سطح دراصل کیا روکتی ہے۔ اگر آپ کا کام ایک ہی repository تک محدود ہے اور machine پر کہیں بھی production credentials موجود نہیں ہیں تو blast radius پہلے ہی محدود ہے۔ اگر agent sessions مختصر اور زیرِ نگرانی ہوں تو exposure window بھی مختصر رہتی ہے۔

جس لمحے آپ prompts کو چھوڑ دیتے ہیں، صورتِ حال بدل جاتی ہے۔ اب یہ بات خاص طور پر اہم ہے کیونکہ auto mode اب Claude Code کا default ہے اور نئی installation files میں ترمیم یا commands چلانے سے پہلے آپ سے اجازت نہیں مانگتی۔ unattended runs، رات بھر چلنے والے jobs، اور وہ تمام workflows جن میں آپ plan approve کرکے چلے جاتے ہیں، اس انسانی جانچ کو ختم کر دیتے ہیں جو containment فراہم کر رہی تھی۔ اس وقت machine کو یہ کام خود کرنا پڑتا ہے۔ یہی بات agent کی رسائی بڑھانے والی ہر چیز پر لاگو ہوتی ہے، جس میں VPS پر coding agent چلانا اور بیک وقت کئی repositories پر کام کرنا بھی شامل ہے۔

فیصلہ دراصل اس بات پر منحصر نہیں کہ آپ model پر کتنا اعتماد کرتے ہیں۔ اصل سوال یہ ہے کہ model کے غلط ہونے کی صورت میں اس کے ساتھ کیا موجود ہے۔

FAQ

coding agent کے لیے container کتنی isolation فراہم کرتا ہے؟

زیادہ تر کاموں کے لیے container کافی ہے، لیکن دو شرائط ہیں۔ container کو --privileged کے ساتھ run نہیں ہونا چاہیے، اور اس میں /var/run/docker.sock mount نہیں ہونا چاہیے، کیونکہ ان میں سے ہر ایک process کو host کے root تک پہنچنے کا راستہ فراہم کرتا ہے۔ container host kernel share کرتا ہے، اس لیے یہ boundary virtual machine کے مقابلے میں کمزور ہے۔ اگر agent انٹرنیٹ سے حاصل کیا گیا untrusted code run کر رہا ہو تو حقیقی VM یا الگ server استعمال کریں۔

کیا agent کو server پر sudo کی ضرورت ہے؟

نہیں۔ اسے sudo دینے سے بنائی گئی isolation ختم ہو جاتی ہے، کیونکہ root machine پر موجود ہر دوسرے account کو پڑھ سکتا ہے۔ agent user کو sudo کے بغیر بنائیں اور اسے صرف اپنی work directory میں write access دیں۔ اگر task کے لیے واقعی package installation ضروری ہو تو ایسی machine دیں جس کا مکمل انتظام agent کے پاس ہو، نہ کہ shared machine پر root access۔

agent کو server پر اپنی SSH key رکھے بغیر git پر push کرنے کی اجازت کیسے دوں؟

connect کرتے وقت ssh -A کے ساتھ اپنا SSH agent forward کریں۔ Signature requests connection کے ذریعے منتقل ہوتی ہیں جبکہ private key آپ کے laptop پر رہتی ہے، اس لیے ssh -T git@github.com authentication کرتا ہے اور git push server پر private key کے بغیر کام کرتا ہے۔ لیکن اس server پر root آپ کے connected رہنے کے دوران forwarded socket استعمال کر سکتا ہے۔ اس لیے ایسی machine پر، جسے آپ دوسرے لوگوں کے ساتھ share کرتے ہیں، repository-scoped deploy key استعمال کریں۔

agent کو کس سائز کے VPS کی ضرورت ہے؟

Agent کا کام زیادہ تر files edit کرنا، builds run کرنا اور tests run کرنا ہوتا ہے، اس لیے machine کا size model کے بجائے build کے مطابق مقرر کریں۔ Hosted model provider کے hardware پر run ہوتا ہے، جس سے network traffic بڑھتا ہے لیکن local load تقریباً نہیں بڑھتا۔ Agent خود پھر بھی کم از کم وسائل کی حد مقرر کرتا ہے: October 20, 2026 تک Claude Code کے system requirements میں کم از کم 4 GB RAM درج ہے۔ Scripting work کے لیے بھی 4 GB سے شروع کریں، اور اگر repository containers build کرتی ہے یا کوئی substantial چیز compile کرتی ہے تو 8 GB پر منتقل ہوں۔

machine کو کتنی بار destroy اور rebuild کرنا چاہیے؟

جب state کی وضاحت ممکن نہ رہے تو rebuild کریں، اور کم از کم اس وقت ضرور rebuild کریں جب machine پر موجود کوئی credential exposed ہونے کا امکان ہو۔ روزمرہ کے drift کے لیے tasks کے درمیان fresh checkout کافی ہوتا ہے، جبکہ پہلے agent run سے پہلے لیا گیا snapshot آپ کو واپس جانے کے لیے clean system image فراہم کرتا ہے۔ اگر rebuilding مہنگی محسوس ہو تو یہ اس بات کی علامت ہے کہ کوئی اہم چیز ایسی machine پر موجود ہے جسے آپ نے disposable کہا تھا۔