Coding agent-এর জন্য disposable VM কেন ব্যবহার করবেন

আপনার ল্যাপটপের চেয়ে disposable VM কেন ভালো

একটি coding agent-কে disposable VM দিলে তার সবচেয়ে খারাপ কাজের ফল হতে পারে এমন একটি মেশিন নষ্ট করা, যেটি আপনি দশ মিনিটে পুনর্নির্মাণ করতে পারবেন। Agent-টি তবুও root access পাবে, package install করবে এবং প্রতিটি ধাপের জন্য অনুমতি না চেয়ে test suite চালাবে। পার্থক্য হলো, ক্ষতিটি কোথায় ঘটবে। ল্যাপটপে agent আপনার SSH key, browser profile, .env file এবং আপনি কখনও clone করেছেন এমন প্রতিটি repository-সহ একই home directory ব্যবহার করে। Throwaway server-এ তার কাছে থাকবে একটি shell, একটি checkout এবং নেওয়ার মতো মূল্যবান আর কিছু নয়।

এটাই মূল যুক্তি। এটি সম্ভাবনার চেয়ে ঝুঁকির অসম বণ্টন নিয়ে যুক্তি। সতর্ক ল্যাপটপে সতর্ক agent প্রায় সব সময়ই ঠিকভাবে কাজ করে। কিন্তু যে একবার তা করে না, তখন ক্ষতি শুধু একটি খারাপ commit নয়। আপনার backup থাকলে backup থেকে restore করতে হবে।

ক্ষতির পরিধি নির্ধারণ করুন, তারপর তা নিয়ে তর্ক করুন

ক্ষতির পরিধি বলতে বোঝায়, কোনো process যে বিষয়গুলোতে পৌঁছাতে পারে সেগুলোর সমষ্টি। আপনার স্বাভাবিক মেশিনে স্বাভাবিক user হিসেবে চলা কোনো agent-এর ক্ষেত্রে এই পরিধি অধিকাংশ মানুষ যতটা ভাবেন, তার চেয়ে বড়।

এর মধ্যে ~/.ssh/id_ed25519 রয়েছে, যা সাধারণত encrypted নয়, কারণ passphrase বারবার টাইপ করতে করতে আপনি ক্লান্ত হয়ে গিয়েছিলেন। এর মধ্যে ~/.aws/credentials এবং ~/.config/gh/hosts.yml রয়েছে, যেগুলো নকশাগতভাবেই plain text। এর মধ্যে ~/code-এর অধীনে থাকা প্রতিটি sibling repository রয়েছে, যার মধ্যে local env file-এ production connection string থাকা repository-ও আছে। এর মধ্যে আপনার shell history-ও রয়েছে, যেখানে আপনি একবার paste করা token রয়ে গেছে। এর মধ্যে আপনার laptop যে network-এ যুক্ত, সেটিও রয়েছে। সেটি প্রায়ই এমন home বা office network, যেখানে unauthenticated service চালু থাকে।

এর কোনোটির জন্য malicious agent প্রয়োজন হয় না। একটি আত্মবিশ্বাসের সঙ্গে ভুল command-ই যথেষ্ট। unset variable-এর প্রসারণে / তৈরি হওয়া rm -rf, ভুল directory-তে চালানো git clean -xfd, আপনার local database-সহ সবকিছু সরিয়ে নেওয়া docker system prune -af --volumes, অথবা home directory-তে চালানো সহায়ক chmod -R 777। Agents সেই একই Internet-এর ওপর প্রশিক্ষিত, যে Internet অন্য সবাইকেও ওই command-গুলো শিখিয়েছে।

আপনাকে যে mechanism সুরক্ষা দেয়, তা agent-এর বিচারবুদ্ধি নয়। বরং ক্ষতি যে machine-এ ঘটবে, সেটি এমন একটি machine যা হারালেও আপনি মেনে নিতে প্রস্তুত ছিলেন।

খরচের হিসাব একঘেয়ে। সেটিই মূল কথা।

একটি ছোট VPS-এর খরচ মাসে কয়েক ডলার। কোনো developer laptop পুনরুদ্ধার করতে এক দিন লাগে। এটি তখনই তুলনামূলক ভালো পরিস্থিতি, যখন আপনি সমস্যাটি সঙ্গে সঙ্গে বুঝতে পারেন এবং আপনার backup থাকে।

নিজের সংখ্যাগুলো দিয়ে হিসাব করুন। আপনার প্রতি ঘণ্টার rate নিন। সেটিকে সেই সময়ের ঘণ্টা দিয়ে গুণ করুন, যত সময় লাগবে operating system পুনরায় install করতে, home directory restore করতে, SSH key rotate করতে, personal access token rotate করতে এবং বিশটি repository আবার clone করতে। এর সঙ্গে আপনার provider-এর বিক্রি করা সবচেয়ে ছোট server-এর বারো মাসের খরচ তুলনা করুন। কয়েক বছরে একটিরও কম incident ঘটলেই খরচের সমতা অতিক্রম করে, এবং সেই সীমা অতিক্রম করার জন্য incident-টি বিপর্যয়কর হওয়ার দরকার নেই। corrupted local environment-এর কারণে একটি বিকেল নষ্ট হলেও এক বছরের server খরচ উঠে যায়।

এই হিসাবের দ্বিতীয় অংশ হলো snapshot। ঝুঁকিপূর্ণ run-এর আগে snapshot নিলে খারাপ ফলাফলের পর "আমার পুরো কাজ restore করুন" পরিস্থিতির বদলে "rollback করে অন্য prompt চেষ্টা করুন" করা যায়। আপনি যে laptop-এ এটি লিখছেন, সেখানে এই সুবিধা নেই। কারণ সেটিকে আপনার কাজের ডেস্ক হিসেবে ব্যবহার করার সময় machine-এর snapshot নেওয়া যায় না।

জুলাই 2026 অনুযায়ী পরিস্থিতি

“এজেন্ট কোথায় চলবে”—এই প্রশ্নের সৎ উত্তর তিনটি। প্রতিটি উত্তরে একই দুটি বিষয়ের মধ্যে ভারসাম্য করতে হয়: boundary কতটা শক্তিশালী এবং আপনি কতটা setup গ্রহণ করতে প্রস্তুত।

একটি local micro VM। এই শ্রেণির tool আপনার নিজের hardware-এ একটি বাস্তব virtual machine চালু করে, repository সেটির মধ্যে mount করে এবং এজেন্টকে ভেতরে root access দেয়। clawk বর্তমানে এর উদাহরণ। এর মূল বক্তব্যও এই পোস্টের thesis-এর সঙ্গে মেলে: coding agent-কে আপনার laptop নয়, একটি সাময়িক Linux VM দিন। জুলাই 2026 অনুযায়ী এটি Apple silicon-এ macOS 14 এবং পরবর্তী version লক্ষ্য করে; Firecracker-এর মাধ্যমে পরীক্ষামূলক Linux support-ও রয়েছে। এটি brew install clawkwork/tap/clawk দিয়ে install হয়। একটি repository-এর মধ্যে clawk চালালে sandbox চালু হয় এবং এজেন্ট সংযুক্ত হয়, clawk down দিয়ে এটি বন্ধ করা যায় এবং clawk destroy দিয়ে মুছে ফেলা যায়। এই boundary একটি hypervisor, তাই এটি শক্তিশালী। সীমাবদ্ধতা হলো VM আপনার সঙ্গে বহন করা machine-এই চলে। ফলে এটি আপনার memory-এর সঙ্গে resource ভাগ করে এবং laptop-এর lid বন্ধ করলে থেমে যায়।

একটি container। Docker এমন একটি উত্তর, যা অধিকাংশ মানুষের system-এ আগে থেকেই install করা থাকে। এটি বাস্তবিকভাবেই উপকারী।

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

--rm exit-এর সময় container মুছে দেয় এবং --network none সেটিকে সম্পূর্ণ network access-বিহীন রাখে। build বা test run-এর জন্য এটি একটি ভালো default। তবে এটি কী করে না, তা স্পষ্টভাবে বুঝুন: container host kernel share করে। তাই kernel-এর bug ব্যবহার করে boundary অতিক্রম করা সম্ভব। আপনি --privileged যোগ করলে অথবা agent-কে “Docker ব্যবহার” করতে দেওয়ার জন্য /var/run/docker.sock mount করলে boundary আর থাকে না। একটি container-এর মধ্যে Docker socket mount করা host-এ ওই container-কে root access দেওয়ার সমতুল্য।

পুনর্নির্মাণ করা যায় এমন একটি সাধারণ VPS। এতে নতুন কোনো tool দরকার হয় না, বাস্তব kernel boundary থাকে, provider snapshot ব্যবহার করা যায় এবং laptop বন্ধ করলেও এটি চলতে থাকে। এই guide-এর বাকি অংশে বর্ণিত pattern-টি এটাই। দীর্ঘ সময় চলা agent-এর ক্ষেত্রেও এটি কার্যকর থাকে, কারণ কোনো job চলতে চার ঘণ্টা লাগলে আপনি বাড়ি চলে গেছেন কি না, তাতে job-এর কিছু যায় আসে না।

VPS প্যাটার্ন: agent-এর জন্য আলাদা user তৈরি করুন

একটি harden করা সিস্টেম দিয়ে শুরু করুন। নতুন VPS-এর প্রথম দশ মিনিট-এ agent-নির্দিষ্ট নয় এমন বিষয়গুলো আছে: update, non-root login, key-only SSH এবং firewall।

এরপর এমন একটি account তৈরি করুন, যা শুধু agent-এর জন্য থাকবে। এতে agent-এর ভেতরের কোনো ভুল সার্ভারের অন্য কিছুতে প্রভাব ফেলতে পারবে না।

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-এর অর্থ হলো অনুমান করার মতো কোনো password নেই। sudo -u agent অথবা SSH key ব্যবহার করে account-এ প্রবেশ করবেন। মনে রাখুন, agent ইচ্ছাকৃতভাবে sudo group-এর সদস্য নয়। sudo থাকা agent-এর root access থাকে। root অন্য সব user-এর file পড়তে পারে। তাই আপনি যে isolation তৈরি করেছেন, তা কেবল নামেই থাকবে। Agent-এর package install করা সত্যিই প্রয়োজন হলে, সেটি agent-এর জন্য সম্পূর্ণ একটি server বরাদ্দ করার কারণ; shared server-এ তাকে sudo দেওয়ার কারণ নয়। সাধারণ নিয়মগুলো VPS-এ Linux user-এর জন্য least privilege-এ দেওয়া আছে।

Agent-কে বিশ্বাস করার আগে isolation boundary পরীক্ষা করুন। agent user হিসেবে নিজের account-এর একটি file পড়ার চেষ্টা করুন:

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

আপনার cat: /home/you/.ssh/id_ed25519: Permission denied দেখা উচিত। এর বদলে key material দেখা গেলে, আপনার home directory-এর mode 755 এবং isolation এখনো কার্যকর নয়। sudo chmod 700 /home/you ব্যবহার করে এটি ঠিক করুন।

ক্রেডেনশিয়াল সম্পূর্ণভাবে মেশিনের বাইরে রাখুন

আপনি production secret মেশিনে কপি করলে disposable machine ব্যবহারের উদ্দেশ্য নষ্ট হয়। নিয়মটি সহজ: ওই মেশিনে এমন কোনো credential থাকা উচিত নয়, যা আজ বিকেলেই rotate করতে আপত্তি হবে।

git-এর জন্য key কপি না করে আপনার SSH agent forward করুন। private key আপনার laptop-এই থাকবে, এবং connection-এর মাধ্যমে শুধু signature request যাবে।

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 সার্ভারে কোনো key file না থাকলেও কাজ করবে। এরপর মেশিনে ls -la ~/.ssh চালিয়ে নিশ্চিত করুন, সেখানে কোনো private key নেই।

Agent forwarding-এর একটি গুরুত্বপূর্ণ ঝুঁকি আছে, তাই বিষয়টি স্পষ্টভাবে বুঝে নিন: আপনি সংযুক্ত থাকা অবস্থায় ওই সার্ভারে root access থাকা যে কেউ forwarded socket ব্যবহার করে আপনার পরিচয়ে authenticate করতে পারে। যে সার্ভারে অন্য কোনো user নেই এবং user একমাত্র আপনি, সেখানে এটি গ্রহণযোগ্য trade-off হতে পারে। Shared machine-এ এটি গ্রহণযোগ্য নয়; সে ক্ষেত্রে একটি repository-নির্দিষ্ট deploy key ব্যবহার করাই ভালো। বিকল্পগুলো SSH key management-এর মৌলিক বিষয়-এ ব্যাখ্যা করা হয়েছে।

API key-এর জন্য agent-কে আলাদা spending limit-সহ নিজস্ব key দিন। এই key এমন একটি file-এ রাখুন, যার owner agent user এবং mode 600। মেশিনটি ধ্বংস করার সময় key-টি revoke করুন, এটি ফাঁস হয়েছে কি না তা নিয়ে অনিশ্চিত থাকবেন না। প্রতিটি key-এর model spend আলাদাভাবে দৃশ্যমান রাখলে VPS-এ AI agent-এর খরচ নিয়ন্ত্রণ-এর সংখ্যাগুলোও পূর্বানুমানযোগ্য থাকে।

এজেন্ট যে নেটওয়ার্কে পৌঁছাতে পারে, তা সীমিত করুন

Filesystem isolation সীমারেখার অর্ধেক মাত্র। বাকি অর্ধেক হলো egress: process-টি কোন endpoint-এর সঙ্গে যোগাযোগ করতে পারবে। 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 rule আটকে দেয়। agent হিসেবে এটি পরীক্ষা করুন:

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

এটি curl: (7) Failed to connect to example.com port 80: Connection refused দিয়ে ব্যর্থ হওয়া উচিত, কারণ reject rule সংযোগটি ঝুলিয়ে না রেখে সঙ্গে সঙ্গে উত্তর দেয়। একই host-এ HTTPS request এখনও সফল হওয়ার কথা।

দুটি সীমাবদ্ধতা মনে রাখুন। প্রথমত, সংরক্ষণ না করলে পরবর্তী reboot-এর সময় এই rules মুছে যাবে। সংরক্ষণ করতে sudo apt install -y iptables-persistent এবং তারপর sudo netfilter-persistent save ব্যবহার করুন। দ্বিতীয়ত, এটি port ও address filter করে, name নয়। 443 port অনুমোদন করলে Internet-এর সব HTTPS host-এ পৌঁছানো যায়। এতে model API-তে পৌঁছানো সম্ভব হয়, পাশাপাশি pastebin-এও পৌঁছানো যায়। প্রকৃত domain allow-list প্রয়োগ করতে traffic এমন একটি proxy-এর মধ্য দিয়ে পাঠাতে হবে, যা requested hostname পড়ে। অধিকাংশ single-developer setup-এর জন্য এটি প্রয়োজনের তুলনায় বেশি অবকাঠামো। আপনি যা বাস্তবে নিয়ন্ত্রণ করেছেন, শুধু সেটুকুই দাবি করুন: এমন একটি machine-এ port-level egress control, যেটি হারিয়ে গেলেও আপনি প্রস্তুত ছিলেন।

কাজের মধ্যে পরিষ্কার অবস্থায় ফিরিয়ে নেওয়া

প্রতিটি কাজের জন্য পরিষ্কার অবস্থা রাখা একটি অবমূল্যায়িত সুবিধা। আগের টিকিটে তিন ঘণ্টা কাজ করা একটি agent ইনস্টল করা package, আংশিকভাবে প্রয়োগ করা migration, পুরোনো node_modules এবং এমন একটি git working tree রেখে গেছে, যাতে কেউ review না করা পরিবর্তন রয়েছে। পরের কাজটি এগুলো সব উত্তরাধিকারসূত্রে পায়। কোন জটিলতা কোন run-এর কারণে তৈরি হয়েছে, তা বোঝার পেছনেই আপনার review budget খরচ হয়। সংকীর্ণ পরিসরের agent শুরুতেই কম অবশিষ্ট রাখে। তাই disposable machine-এর সঙ্গে agent-কে কাজের জন্য প্রয়োজনীয় সর্বনিম্ন পরিবর্তনের দিকে পরিচালিত করে এমন একটি skill ব্যবহার করলে diff এবং অবশিষ্ট state—দুটিই review করার মতো ছোট থাকে।

এর সহজতম পদ্ধতি হলো প্রতিটি কাজের জন্য fresh checkout ব্যবহার করা।

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

আরও শক্তিশালী পদ্ধতি হলো machine সেটআপ করার পর, কোনো agent তাতে কাজ করার আগে একবার provider snapshot নেওয়া। এই snapshot restore করলে package-সহ পুরো system একটি পরিচিত অবস্থায় ফিরে আসে। অধিকাংশ provider এটি machine-এর command হিসেবে নয়, control panel বা API-এর মাধ্যমে দেয়। তাই নির্দিষ্ট ধাপ আপনার provider-এর ওপর নির্ভর করবে। মূল নিয়ম হলো machine এখনও কোনো পরিবর্তন ছাড়াই পরিষ্কার থাকা অবস্থায় snapshot নেওয়া।

যে কোনো গুরুত্বপূর্ণ জিনিস disposable machine-এর বাইরে রাখুন। সাধারণত এর অর্থ branch স্থানীয়ভাবে জমিয়ে না রেখে push করা। machine-এ এমন কিছু থেকে গেলে যা হারালে সমস্যা হবে, VPS-এ restic backup ব্যবহার করে সঠিকভাবে backup নিন। যে machine ধ্বংস করা যায়, সেটি তখনই কার্যকর যখন ধ্বংস করলেও বাস্তবে কোনো জটিলতা তৈরি হয় না।

একাধিক server-এর জন্য অর্থ খরচ না করে কয়েকটি isolated environment চাইলে একটি বড় VPS সরাসরি guest VM host করতে পারে। VPS-এ nested virtualisation-এ এটি কীভাবে কাজ করে এবং আপনার provider এটি অনুমোদন করে কি না কীভাবে যাচাই করবেন, তা ব্যাখ্যা করা হয়েছে। এখানে isolation উভয় দিকেই কাজ করে। একই box-এ দুটি agent-কে সমন্বয় করাতে চাইলে, একে অপরের কাছ থেকে সম্পূর্ণ বিচ্ছিন্ন না রেখে, একটি Claude Code session সরাসরি অন্যটিতে text পাঠাতে পারে। এতে প্রতিটি handoff আপনার মাধ্যমে পাঠানোর প্রয়োজন হয় না।

সতর্কতা মেনে ব্যবহার করা laptop যথেষ্ট নিরাপদ হওয়ার সময়

এ বিষয়ে সৎ থাকুন। Isolation অতিরঞ্জিত করে বললে মানুষ পরে আর সতর্কবার্তা শুনবে না।

প্রতিটি command চালানোর আগে আপনি যদি তা পর্যালোচনা করেন, তাহলে laptop যথেষ্ট নিরাপদ। Permission prompt একটি কার্যকর নিয়ন্ত্রণ। server-এ Claude Code নিরাপদে চালানো নির্দেশিকায় প্রতিটি permission level আসলে কী কী বন্ধ করে, তা ব্যাখ্যা করা হয়েছে। আপনার কাজ যদি এমন একটি repository-তে সীমাবদ্ধ থাকে, যেখানে ওই machine-এ কোনো production credential নেই, তাহলে সম্ভাব্য ক্ষতির পরিধি শুরু থেকেই ছোট। Agent session সংক্ষিপ্ত এবং আপনার তত্ত্বাবধানে হলে exposure window-ও ছোট থাকে।

আপনি prompt এড়িয়ে গেলে সিদ্ধান্ত বদলে যায়। বিশেষ করে এখন এটি বিবেচনা করা জরুরি, কারণ 14 August 2026-এ auto mode Claude Code-এর default হওয়া শুরু হবে এবং নতুন installation file edit বা command চালানোর আগে আর অনুমতি চাইবে না। Unattended run, রাতভর চলা job এবং এমন workflow যেখানে আপনি একটি plan অনুমোদন করে সরে যান—এসব ক্ষেত্রে containment নিশ্চিত করা মানবিক যাচাইটি আর থাকে না। তখন machine-কেই সেই কাজ করতে হয়। Agent-এর reach বাড়ায় এমন যেকোনো ব্যবস্থার ক্ষেত্রেও একই কথা প্রযোজ্য, যার মধ্যে একসঙ্গে একাধিক repository-তে VPS-এ coding agent চালানো অন্তর্ভুক্ত।

সিদ্ধান্তটি আসলে model-কে আপনি কতটা বিশ্বাস করেন, তা নিয়ে নয়। Model ভুল করলে তার পাশে কী কী access ও resource রয়েছে, সিদ্ধান্তটি তা নিয়ে।

FAQ

একটি container কি coding agent-এর জন্য যথেষ্ট isolation দেয়?

বেশিরভাগ কাজের জন্য দেয়, তবে 2টি শর্ত আছে। container-টি --privileged দিয়ে চালানো যাবে না এবং এর মধ্যে /var/run/docker.sock mount করা যাবে না, কারণ যেকোনো একটি process-কে host-এর root account-এ পৌঁছানোর পথ দেয়। একটি container host kernel share করে, তাই এর isolation boundary virtual machine-এর তুলনায় দুর্বল। agent Internet থেকে আনা untrusted code চালালে একটি বাস্তব VM বা আলাদা server ব্যবহার করুন।

server-এ agent-এর কি sudo দরকার?

না। agent-কে sudo দিলে তৈরি করা isolation নষ্ট হয়ে যায়, কারণ root account server-এর অন্য সব account পড়তে পারে। sudo ছাড়া agent user তৈরি করুন এবং শুধু তার নিজস্ব work directory-তে write access দিন। কাজটির জন্য সত্যিই package installation দরকার হলে, অন্যদের সঙ্গে share করা machine-এ root access দেওয়ার বদলে agent-এর মালিকানাধীন একটি সম্পূর্ণ machine দিন।

server-এ আমার SSH key না রেখে agent-কে git-এ push করতে কীভাবে দেব?

সংযোগ করার সময় ssh -A দিয়ে আপনার SSH agent forward করুন। private key আপনার laptop-এই থাকবে এবং signature request সংযোগের মাধ্যমে যাবে, তাই ssh -T git@github.com authentication করবে এবং server-এ কোনো private key না রেখেই git push কাজ করবে। তবে আপনি connected থাকা অবস্থায় ওই server-এর root account forwarded socket ব্যবহার করতে পারে। তাই অন্যদের সঙ্গে share করা যেকোনো machine-এ repository-scoped deploy key ব্যবহার করুন।

একটি agent-এর জন্য কী আকারের VPS দরকার?

agent-এর কাজ মূলত file edit করা, build চালানো এবং test চালানো। তাই model-এর জন্য নয়, build-এর জন্য machine-এর আকার নির্ধারণ করুন। hosted model provider-এর hardware-এ চলে, ফলে network traffic বাড়ে কিন্তু local load প্রায় বাড়ে না। scripting work-এর জন্য 2 GB RAM দিয়ে শুরু করুন। repository container build করলে বা বড় কোনো জিনিস compile করলে 8 GB-এ যান।

কত ঘন ঘন machine ধ্বংস করে পুনর্নির্মাণ করা উচিত?

state আর ব্যাখ্যা করা না গেলে rebuild করুন। এছাড়া machine-এ থাকা কোনো credential exposed হয়ে থাকতে পারে এমন প্রতিবারই rebuild করুন। প্রতিটি কাজের আগে fresh checkout নিলে দৈনন্দিন drift সামলানো যায়। প্রথম agent run-এর আগে নেওয়া snapshot আপনাকে ফিরে যাওয়ার জন্য একটি clean system image দেয়। rebuild ব্যয়বহুল মনে হলে বুঝবেন, disposable হিসেবে নির্ধারিত machine-এ গুরুত্বপূর্ণ কোনো state থাকা উচিত নয়।