Coding agents కోసం disposable VM ఎందుకు మంచిది

ల్యాప్‌టాప్‌ కంటే తాత్కాలిక VM ఎందుకు మెరుగైనది

ఒక coding agent కు తిరిగి నిర్మించగలిగే తాత్కాలిక VM ఇవ్వండి. అప్పుడు అది చేయగలిగే అత్యంత తీవ్రమైన పని, పది నిమిషాల్లో మళ్లీ నిర్మించగలిగే యంత్రాన్ని ధ్వంసం చేయడమే. ఆ agent కు ఇంకా root యాక్సెస్ ఉంటుంది. అది ఇంకా packages install చేయగలదు. ప్రతి దశకు అనుమతి అడగకుండా test suite ను అమలు చేయగలదు. తేడా నష్టం ఎక్కడ జరుగుతుందనేదే. ల్యాప్‌టాప్‌లో, మీ SSH keys, browser profile, మీ .env files, అలాగే మీరు ఎప్పుడైనా clone చేసిన ప్రతి repository ఉన్న home directory ను agent మీతో పంచుకుంటుంది. పారేయగల server లో దానికి shell, checkout మాత్రమే ఉంటాయి. దొంగిలించడానికి విలువైన ఇతర సమాచారం ఏదీ ఉండదు.

ఇదే మొత్తం వాదన. ఇది సంభావ్యత గురించి కాకుండా, అసమాన ప్రభావం గురించి. జాగ్రత్తగా ఉన్న ల్యాప్‌టాప్‌లో జాగ్రత్తగా పనిచేసే agent దాదాపు ప్రతిసారీ సమస్య లేకుండా పనిచేస్తుంది. కానీ ఒకసారి అది విఫలమైతే, నష్టం కేవలం తప్పు commit కాదు. మీ వద్ద backup ఉంటే, దాని నుంచి restore చేయాల్సి వస్తుంది.

నష్టం పరిధి గురించి వాదించే ముందు అది ఎంతవరకు విస్తరిస్తుందో గుర్తించండి

నష్టం పరిధి అంటే ఒక process చేరుకోగల అంశాల సముదాయం. మీ సాధారణ machineలో మీ సాధారణ userగా నడుస్తున్న agentకు ఆ సముదాయం చాలామంది ఊహించేదానికంటే పెద్దది.

అందులో ~/.ssh/id_ed25519 కూడా ఉంటుంది. passphrase టైప్ చేయడం విసుగుగా అనిపించినందున అది సాధారణంగా unencryptedగా ఉంటుంది. అందులో ~/.aws/credentials మరియు ~/.config/gh/hosts.yml కూడా ఉంటాయి. అవి ఉద్దేశపూర్వకంగానే plain textగా ఉంటాయి. ~/code కింద ఉన్న ప్రతి sibling repository కూడా ఇందులో ఉంటుంది. వాటిలో local env fileలో production connection strings ఉన్న repositories కూడా ఉండవచ్చు. మీరు ఒకసారి paste చేసిన tokensను కలిగి ఉన్న shell history కూడా ఇందులో ఉంటుంది. మీ laptop అనుసంధానమైన network కూడా ఇందులో ఉంటుంది. అది తరచుగా unauthenticated services ఉన్న home లేదా office network అయి ఉంటుంది.

ఇవేవీ malicious agent అవసరం లేకుండానే జరుగుతాయి. ఒక తప్పుగా నమ్మకంతో అమలు చేసిన command చాలు. BUILD_DIR unsetగా ఉన్న rm -rf "$BUILD_DIR"/*, ఇది /*గా విస్తరించి GNU rm యొక్క default refusalను దాటి /నే తొలగించవచ్చు; తప్పు directoryలోని git clean -xfd; దానితో పాటు మీ local databaseను తొలగించే docker system prune -af --volumes; home directoryపై అమలు చేసిన సహాయకంగా కనిపించే chmod -R 777. ఆ commandsను అందరికీ నేర్పిన అదే internetపై agents కూడా శిక్షణ పొందాయి.

మిమ్మల్ని రక్షించే mechanism agent యొక్క judgment కాదు. నష్టాన్ని భరించాల్సి వచ్చినా కోల్పోవడానికి మీరు సిద్ధంగా ఉన్న machineలోనే ఆ నష్టం పరిమితమై ఉండటమే రక్షణ.

ఖర్చు లెక్కలు ఆసక్తికరంగా ఉండకపోవచ్చు; అదే ఉద్దేశం

చిన్న VPS కు నెలకు కొన్ని డాలర్లు మాత్రమే ఖర్చవుతాయి. Developer laptop ను పునరుద్ధరించడానికి ఒక రోజు పడవచ్చు. వెంటనే సమస్యను గుర్తించి, backup అందుబాటులో ఉన్నప్పుడు ఇది అనుకూలమైన పరిస్థితి.

మీ స్వంత సంఖ్యలతో లెక్కించండి. మీ గంట రేటును తీసుకుని, operating system ను మళ్లీ install చేయడానికి, home directory ను restore చేయడానికి, SSH key ను rotate చేయడానికి, personal access token ను rotate చేయడానికి, అలాగే ఇరవై repositories ను మళ్లీ clone చేయడానికి పట్టే గంటల సంఖ్యతో గుణించండి. ఆ మొత్తాన్ని మీ provider విక్రయించే అతి చిన్న server కు పన్నెండు నెలల ఖర్చుతో పోల్చండి. ఈ లెక్కలో సమతుల్య స్థానం అనేక సంవత్సరాలకు ఒక incident కంటే తక్కువగానే ఉంటుంది. ఆ పరిమితిని దాటడానికి incident చాలా తీవ్రమైనదై ఉండాల్సిన అవసరం లేదు. corrupted local environment కారణంగా కోల్పోయిన ఒక్క మధ్యాహ్నమే ఆ సంవత్సరపు ఖర్చును భర్తీ చేస్తుంది.

ఈ లెక్కలో రెండో భాగం snapshots. ప్రమాదకరమైన run కు ముందు snapshot తీసుకుంటే, చెడు ఫలితాన్ని "నా మొత్తం పని వాతావరణాన్ని restore చేయాలి" అనే పరిస్థితి నుంచి "rollback చేసి వేరే prompt తో ప్రయత్నించాలి" అనే పరిస్థితిగా మార్చవచ్చు. మీరు దీన్ని టైప్ చేస్తున్న laptop లో ఈ అవకాశం ఉండదు. ఎందుకంటే దానిని మీ desk గా ఉపయోగిస్తున్నప్పుడే machine యొక్క snapshot తీసుకోలేరు.

2026 October నాటికి పరిస్థితి

“ఏజెంట్‌ను ఎక్కడ నడపాలి?” అనే ప్రశ్నకు నిజాయితీగా చెప్పగల మూడు సమాధానాలు ఉన్నాయి. వీటిలో ఒకే రెండు అంశాల మధ్య సమతుల్యం ఉంటుంది: boundary ఎంత బలంగా ఉంది, మరియు మీరు ఎంత setup ను భరించగలరు.

ఒక local micro VM. ఈ వర్గంలోని tools మీ hardware పై నిజమైన virtual machine ను boot చేసి, మీ repository ను అందులో mount చేస్తాయి. ఆ VM లో ఏజెంట్‌కు root ఇస్తాయి. clawk ప్రస్తుతం దీనికి ఉదాహరణ. ఈ post యొక్క ప్రధాన ఉద్దేశం కూడా ఇదే: coding agents కోసం మీ laptop కాకుండా ఉపయోగించిన తర్వాత తొలగించగల Linux VM ఇవ్వాలి. 2026 October నాటికి ఇది Apple silicon పై macOS 14 మరియు తరువాతి versions ను target చేస్తుంది. Firecracker ద్వారా experimental Linux support కూడా ఉంది. దీన్ని brew install clawkwork/tap/clawk తో install చేస్తారు. Repository లో clawk నడిపితే sandbox boot అయి agent attach అవుతుంది. దాన్ని ఆపడానికి clawk down, తొలగించడానికి clawk destroy ఉపయోగించాలి. Boundary ను hypervisor అందిస్తుంది కాబట్టి అది బలంగా ఉంటుంది. పరిమితి ఏమిటంటే VM మీరు వెంట తీసుకెళ్లే machine పైనే నడుస్తుంది. అందువల్ల అది మీ memory కోసం పోటీ పడుతుంది. మీరు laptop lid మూసినప్పుడు అది ఆగిపోతుంది.

ఒక container. చాలా మంది ఇప్పటికే install చేసుకున్న Docker సాధారణ ఎంపిక. ఇది వాస్తవంగా ఉపయోగకరమైనదే.

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 పూర్తిగా తొలగిపోతుంది. Docker socket ను container లోకి mount చేయడం అంటే ఆ container కు host పై root access ఇచ్చినట్లే.

మీరు మళ్లీ rebuild చేయగల సాధారణ VPS. కొత్త tool అవసరం లేదు. నిజమైన kernel boundary ఉంటుంది. Provider snapshots ఉంటాయి. మీరు laptop ను మూసివేసిన తర్వాత కూడా ఇది నడుస్తూనే ఉంటుంది. ఈ guide లోని మిగతా భాగం వివరించే pattern ఇదే. ఎక్కువసేపు నడిచే agents కోసం కూడా ఇది అనుకూలంగా ఉంటుంది. ఎందుకంటే నాలుగు గంటలు పట్టే job కు మీరు ఇంటికి వెళ్లారా లేదా అన్నది ముఖ్యం కాదు.

VPS విధానం: agent కోసం ప్రత్యేక user ను సృష్టించండి

Hardened box తో ప్రారంభించండి. కొత్త VPS పై మొదటి పది నిమిషాలు agent కు ప్రత్యేకం కాని అంశాలను కవర్ చేస్తాయి: updates, non-root login, key-only SSH, firewall.

తర్వాత agent కోసం మాత్రమే ఉండే account ను సృష్టించండి. దానిలో జరిగే పొరపాటు 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 అంటే ఊహించడానికి password ఉండదు. మీరు ఆ account ను sudo -u agent లేదా SSH key తో access చేస్తారు. agent ను ఉద్దేశపూర్వకంగా sudo group లో చేర్చలేదని గమనించండి. sudo ఉన్న agent కు root access ఉంటుంది. root ఇతర users కు చెందిన అన్ని files ను చదవగలదు. అప్పుడు మీరు ఇప్పుడే ఏర్పాటు చేసిన విభజనకు ఉపయోగం ఉండదు. Agent కు packages install చేయడం నిజంగా అవసరమైతే, shared server పై దానికి sudo ఇవ్వడం కంటే, agent స్వంతంగా ఉపయోగించే పూర్తి server ను కేటాయించాలి. సాధారణ నియమాల కోసం VPS లో Linux users కు least privilege చూడండి.

దానిని నమ్మే ముందు ఈ boundary ను తనిఖీ చేయండి. agent user గా, మీ account కు చెందిన home directory ను list చేయడానికి ప్రయత్నించండి:

sudo -u agent ls /home/you

మీకు ls: cannot open directory '/home/you': Permission denied కనిపించాలి. దాని బదులు file listing కనిపిస్తే, మీ home directory ను ఇతర users చదవగలరు. ప్రత్యేకంగా access పరిమితం చేయని world-readable .env file వంటి ఏదైనా file ను agent చదవగలదు. sudo chmod 700 /home/you తో దాన్ని సరిచేయండి. ఈ test మీ private SSH key ను రక్షించదు. ఇతర users access చేయగల private key file ను ssh పట్టించుకోదు. అందువల్ల మీకు పనిచేసే ఏ key అయినా ఇప్పటికే agent కు unreadable గా ఉంటుంది; మీ home directory యొక్క mode ఏదైనా కావచ్చు.

ఆధారాలను పూర్తిగా మెషీన్‌కు దూరంగా ఉంచండి

మీ production secrets ను disposable machine పైకి కాపీ చేస్తే, దాని ప్రధాన ఉద్దేశమే నెరవేరదు. నియమం సులభం: ఆ మెషీన్‌లో, ఈ మధ్యాహ్నం మార్చాల్సి వచ్చినా మీకు అభ్యంతరం కలిగించే credential ఏదీ ఉండకూడదు.

git కోసం key ను కాపీ చేయడానికి బదులుగా మీ SSH agent ను forward చేయండి. Private key మీ laptop పైనే ఉంటుంది. Signature requests మాత్రమే connection ద్వారా వెళ్తాయి.

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. అనే సమాధానం రావాలి. దీని ద్వారా server పై key file లేకపోయినా git push పనిచేస్తుందని నిర్ధారించవచ్చు. తరువాత ఆ మెషీన్‌పై ls -la ~/.ssh అమలు చేసి, అందులో private key లేదని నిర్ధారించండి.

Agent forwarding కు ఒక ముఖ్యమైన పరిమితి ఉంది. దాన్ని స్పష్టంగా గుర్తుంచుకోండి: మీరు connected గా ఉన్న సమయంలో, ఆ server పై root యాక్సెస్ ఉన్న ఎవరైనా forwarded socket ను ఉపయోగించి మీ తరఫున authenticate చేయగలరు. ఆ server లో మీరు మాత్రమే ఇతర user అయితే, ఇది అంగీకరించదగిన మార్పిడి. Shared box లో ఇది సరైనది కాదు. అలాంటి సందర్భంలో ఒక repository కు మాత్రమే పరిమితం చేసిన deploy key ఉత్తమ ఎంపిక. ఈ ఎంపికలను SSH key నిర్వహణ ప్రాథమికాలు లో వివరించాం.

API keys కోసం agent కు ప్రత్యేక spending limit ఉన్న ప్రత్యేక key ఇవ్వండి. దాన్ని agent user సొంతమైన file లో mode 600 తో నిల్వ చేయండి. Machine ను తొలగించినప్పుడు, key లీక్ అయిందా అని ఆలోచించకుండా దాన్ని revoke చేయండి. ప్రతి key కు model spend ను కనిపించేలా ఉంచడం వల్ల VPS పై AI agent ఖర్చు నియంత్రణ లోని సంఖ్యలు కూడా అంచనా వేయదగినవిగా ఉంటాయి.

ఏ నెట్‌వర్క్ వనరులను agent చేరుకోగలదో పరిమితం చేయండి

Filesystem isolation అనేది పరిమితిలో సగం మాత్రమే. మిగిలిన సగం egress: process ఎవరితో network ద్వారా మాట్లాడగలదో అది. Linux, process ను సృష్టించిన user ఆధారంగా బయటికి వెళ్లే 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 వరుస క్రమంలో చదవబడతాయి. అందువల్ల ముందరి lines అనుమతించని ప్రతిదానిని చివరి REJECT rule అడ్డుకుంటుంది. దీన్ని agent గా పరీక్షించండి:

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

ఇది వెంటనే curl: (7) Failed to connect to example.com error తో విఫలమవ్వాలి. తరువాత కనిపించే wording మీ curl version ఆధారంగా మారవచ్చు. Reject rule connection hang అయ్యేలా చేయకుండా వెంటనే సమాధానం ఇస్తుంది కాబట్టి ఇది జరుగుతుంది. అదే host కు HTTPS request మాత్రం విజయవంతం కావాలి.

ఇక్కడ రెండు ముఖ్యమైన పరిమితులు ఉన్నాయి. మొదటిది, వాటిని save చేయకపోతే తదుపరి reboot సమయంలో ఈ rules పోతాయి. వాటిని sudo apt install -y iptables-persistent తో save చేసి, తరువాత sudo netfilter-persistent save ఉపయోగించండి. రెండవది, ఈ విధానం names ను కాకుండా ports మరియు addresses ను filter చేస్తుంది. Port 443 ను అనుమతించే rule internet లోని ప్రతి HTTPS host కు అనుమతి ఇస్తుంది. అందువల్ల model API ను చేరుకోవచ్చు, అలాగే pastebin ను కూడా చేరుకోవచ్చు. నిజమైన domain allow-list కోసం requested hostname ను చదివే proxy ద్వారా traffic వెళ్లాలి. చాలా single-developer setups కు ఇది అవసరమైనదానికంటే ఎక్కువ వ్యవస్థాపన. మీ వద్ద నిజంగా ఉన్న నియంత్రణను మాత్రమే పేర్కొనండి: మీరు కోల్పోయినా నిర్వహించగలిగే machine పై port-level egress control.

పనుల మధ్య శుభ్రమైన స్థితికి తిరిగి వెళ్లడం

ప్రతి పనికి శుభ్రమైన స్థితి ఉండటం తరచుగా తక్కువగా అంచనా వేసే ప్రయోజనం. గత ticket పై మూడు గంటలు పనిచేసిన agent ఇన్‌స్టాల్ చేసిన packages, సగం అమలైన migrations, పాత node_modules, ఇంకా ఎవరూ review చేయని మార్పులతో కూడిన git working tree ను వదిలి ఉండవచ్చు. తదుపరి పని ఇవన్నీ వారసత్వంగా పొందుతుంది. ఏ గందరగోళం ఏ run కు చెందిందో గుర్తించడానికే మీ review సమయం ఖర్చవుతుంది. పరిమిత పరిధి ఉన్న agent మొదటి నుంచే తక్కువ అవశేషాలను వదిలి వెళ్తుంది. అందువల్ల disposable machine ను పనిచేసే అతి చిన్న మార్పు వైపు agent ను నడిపించే skill తో కలిపితే diff మరియు మిగిలిన స్థితి రెండూ review చేయగల పరిమాణంలో ఉంటాయి.

సులభమైన విధానం ప్రతి పనికి fresh checkout ఉపయోగించడం.

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

మరింత బలమైన విధానం machine setup పూర్తయిన వెంటనే, ఏ agent దానిపై పని చేయకముందే provider snapshot తీసుకోవడం. ఆ snapshot ను restore చేస్తే packages సహా మొత్తం system తెలిసిన స్థితికి తిరిగి వస్తుంది. చాలా providers దీన్ని machine పై command రూపంలో కాకుండా control panel లేదా API ద్వారా అందిస్తారు. అందువల్ల ఖచ్చితమైన దశలు మీ provider పై ఆధారపడి ఉంటాయి. Machine ఇంకా ఎలాంటి మార్పులు లేని స్థితిలో ఉన్నప్పుడే snapshot తీసుకోవాలి.

మీకు అవసరమైనదేదైనా disposable machine వెలుపల ఉంచండి. సాధారణంగా దీని అర్థం branches ను స్థానికంగా దాచకుండా push చేయడం. Machine లో మీరు కోల్పోవాలనుకోని ఏదైనా మిగిలితే, VPS పై restic backups తో సరైన backup తీసుకోండి. నాశనం చేయగల machine ఉపయోగకరంగా ఉండాలంటే, దాన్ని నాశనం చేయడం నిజంగా ఎలాంటి సమస్యలు లేకుండా జరగాలి.

అనేక servers కోసం చెల్లించకుండా పలు isolated environments కావాలంటే, ఒక పెద్ద VPS guest VMs ను నేరుగా host చేయగలదు. VPS పై Nested virtualisation ఇది ఎలా పనిచేస్తుందో వివరిస్తుంది. Provider దాన్ని అనుమతిస్తుందో లేదో ఎలా తనిఖీ చేయాలో కూడా అందులో ఉంది. ఇక్కడ isolation రెండు వైపులా ప్రభావం చూపుతుంది. ఒకే box పై ఉన్న ఇద్దరు agents పరస్పరం సమన్వయం చేసుకోవడం మీకు అనుకూలమైతే, ప్రతి handoff ను మీ ద్వారా పంపించకుండా ఒక Claude Code session మరో session కు నేరుగా text పంపగలదు.

శ్రద్ధగా ఉపయోగించే laptop నిజంగా సరిపడే సందర్భం

దీని గురించి నిజాయితీగా ఉండాలి. Isolation సామర్థ్యాన్ని అతిగా ప్రచారం చేస్తే, ప్రజలు వినడం మానేస్తారు.

ప్రతి command అమలు కావడానికి ముందు మీరు దాన్ని పరిశీలిస్తే laptop సరిపోతుంది. Permission prompt ఒక నిజమైన నియంత్రణ. సర్వర్‌పై Claude Code ను సురక్షితంగా నడపడంలో ప్రతి permission స్థాయి వాస్తవంగా ఏమి నిరోధిస్తుందో వివరించబడుతుంది. మీ పని ఒక్క repositoryకే పరిమితమై, ఆ machineలో production credentials ఎక్కడా లేకపోతే, blast radius ఇప్పటికే చిన్నదే. మీ agent sessions తక్కువసేపు ఉండి, పర్యవేక్షణలో నడిస్తే exposure window కూడా తక్కువగానే ఉంటుంది.

మీరు prompts ను దాటవేసిన క్షణం నుంచి సమాధానం మారుతుంది. ఇప్పుడు ఇది మరింత ముఖ్యమైన విషయం, ఎందుకంటే auto mode ఇప్పుడు Claude Code యొక్క defaultగా ఉంది. కొత్తగా install చేసినప్పుడు files edit చేయడానికి లేదా commands నడపడానికి ముందు ఇకపై మీ అనుమతి అడగదు. Unattended runs, overnight jobs, అలాగే మీరు ఒక plan ను approve చేసి అక్కడి నుంచి వెళ్లిపోయే workflowలు containment ను అందిస్తున్న మానవ తనిఖీని తొలగిస్తాయి. అప్పుడు machine ఆ నియంత్రణను స్వయంగా నిర్వహించాలి. Agent పరిధిని విస్తరించే ఏ విషయానికైనా ఇదే వర్తిస్తుంది. ఉదాహరణకు అనేక repositoryలపై ఒకేసారి VPSలో coding agent ను నడపడం.

ఈ నిర్ణయం modelపై మీరు ఎంత నమ్మకం ఉంచుతున్నారనే దాని గురించి కాదు. Model తప్పు చేసినప్పుడు దాని పక్కన ఏ నియంత్రణలు ఉన్నాయనేదే అసలు విషయం.

FAQ

coding agent కోసం container isolation సరిపోతుందా?

చాలా పనులకు సరిపోతుంది, అయితే రెండు షరతులు ఉన్నాయి. Container --privileged తో run కాకూడదు. అలాగే /var/run/docker.sock ను దానిలో mount చేయకూడదు. వీటిలో ఏదైనా ఉంటే process కు host పై root స్థాయికి చేరే మార్గం లభిస్తుంది. Container, host kernel ను share చేస్తుంది. అందువల్ల virtual machine తో పోలిస్తే isolation boundary బలహీనంగా ఉంటుంది. Agent internet నుంచి తీసుకున్న untrusted code ను run చేస్తుంటే, నిజమైన VM లేదా ప్రత్యేక server ను ఉపయోగించండి.

Server పై agent కు sudo అవసరమా?

అవసరం లేదు. దానికి sudo ఇవ్వడం ద్వారా మీరు ఏర్పాటు చేసిన isolation తొలగిపోతుంది. కారణం, root కు ఆ machine లోని ప్రతి ఇతర account ను చదవగల సామర్థ్యం ఉంటుంది. sudo లేకుండా agent user ను create చేయండి. దాని స్వంత work directory కి మాత్రమే write access ఇవ్వండి. Task కు నిజంగా package installation అవసరమైతే, ఇతరులతో share చేసే machine పై root access ఇవ్వడం కంటే agent స్వంతంగా ఉపయోగించే పూర్తి machine ను ఇవ్వండి.

నా SSH key ను machine పై ఉంచకుండా agent ను git కు push చేయించాలంటే ఎలా?

Connect చేసేటప్పుడు మీ SSH agent ను ssh -A తో forward చేయండి. Private key మీ laptop లోనే ఉంటుంది. Signature requests connection ద్వారా పంపబడతాయి. అందువల్ల ssh -T git@github.com authenticate అవుతుంది, అలాగే server పై private key లేకుండానే git push పనిచేస్తుంది. అయితే మీరు connect అయి ఉన్న సమయంలో ఆ server పై root, forwarded socket ను ఉపయోగించగలదు. కాబట్టి ఇతరులతో share చేసే ఏ machine లోనైనా repository-scoped deploy key ను ఉపయోగించండి.

Agent కు ఎంత పరిమాణం ఉన్న VPS అవసరం?

Agent పని ప్రధానంగా files edit చేయడం, builds run చేయడం, tests run చేయడం వంటివి. అందువల్ల machine పరిమాణాన్ని model కోసం కాకుండా build కోసం నిర్ణయించండి. Hosted model provider hardware పై run అవుతుంది. దీనివల్ల network traffic పెరుగుతుంది, కానీ local load దాదాపు ఉండదు. అయినప్పటికీ agent స్వయంగా కనీస వనరుల పరిమితిని నిర్ణయిస్తుంది. October 20, 2026 నాటికి, Claude Code system requirements లో కనీసం 4 GB RAM అవసరమని పేర్కొంది. Scripting పనులకు కూడా 4 GB తో ప్రారంభించండి. Repository containers build చేస్తే లేదా గణనీయమైన compilation చేస్తే 8 GB కు పెంచండి.

Machine ను ఎంత తరచుగా destroy చేసి rebuild చేయాలి?

Machine state ను ఇకపై కారణాలతో వివరించలేనప్పుడు rebuild చేయండి. కనీసం, machine పై ఉన్న ఏదైనా credential బయటపడే అవకాశం ఉన్నప్పుడల్లా rebuild చేయండి. రోజువారీ మార్పులను నియంత్రించడానికి tasks మధ్య fresh checkout చేయండి. మొదటి agent run కు ముందు snapshot తీసుకోండి. అప్పుడు తిరిగి ఉపయోగించగల clean system image మీ వద్ద ఉంటుంది. Rebuilding ఖరీదైనదిగా అనిపిస్తే, మీరు disposable గా పిలిచిన machine పై ముఖ్యమైనదేదో ఆధారపడి ఉందని అర్థం.