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 చేయాల్సి వస్తుంది.

వాదించే ముందు నష్టం వ్యాప్తిని నిర్వచించండి

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

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

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

మిమ్మల్ని రక్షించేది agent యొక్క judgement కాదు. నష్టం జరిగిన 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 నాటికి పరిస్థితి

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

ఒక local micro VM. ఈ వర్గంలోని tools మీ స్వంత hardware పై నిజమైన virtual machine ను boot చేసి, మీ repository ను దానిలో mount చేస్తాయి. ఏజెంట్‌కు దాని లోపల root access ఉంటుంది. clawk ప్రస్తుతం దీనికి ఉదాహరణ. ఈ post యొక్క ప్రధాన ఉద్దేశం కూడా ఇదే: coding agents కోసం మీ laptop కాకుండా ఉపయోగం పూర్తయ్యాక తొలగించగల Linux VM ఇవ్వడం. July 2026 నాటికి ఇది Apple silicon పై macOS 14 మరియు తదుపరి versions ను target చేస్తుంది. Firecracker ద్వారా experimental Linux support కూడా ఉంది. దీన్ని brew install clawkwork/tap/clawk తో install చేయవచ్చు. Sandbox ను boot చేసి agent ను attach చేయడానికి repository లోపల clawk ను run చేయాలి. ఆపడానికి 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 ఇవ్వడమే.

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

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

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

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

దానిపై నమ్మకం ఉంచే ముందు ఈ పరిమితిని తనిఖీ చేయండి. 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 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 చేరుకోగలదో పరిమితం చేయండి

ఫైల్‌సిస్టమ్ isolation అనేది boundary లో సగం మాత్రమే. మిగిలిన సగం egress: process ఏ గమ్యస్థానాలతో network ద్వారా సంభాషించగలదో అది. 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 క్రమంగా చదవబడతాయి. అందువల్ల ముందున్న lines అనుమతించని ప్రతిదాన్ని చివరి 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 వెంటనే సమాధానం ఇస్తుంది; connection hang అవ్వడానికి అనుమతించదు. అదే host కు HTTPS request మాత్రం విజయవంతం కావాలి.

ఇక్కడ రెండు ముఖ్యమైన పరిమితులు ఉన్నాయి. మొదటిది, మీరు వాటిని save చేయకపోతే తదుపరి reboot సమయంలో ఈ rules తొలగిపోతాయి. వాటిని sudo apt install -y iptables-persistent తో save చేసి, తరువాత sudo netfilter-persistent save తో restore చేయాలి. రెండవది, ఇది 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 పంపగలదు.

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

ఈ విషయంపై నిజాయితీగా ఉండాలి. వేరుచేయడాన్ని అతిగా ప్రచారం చేస్తే, ప్రజలు వినడం ఆపేస్తారు.

ప్రతి command నడిచే ముందు మీరు పరిశీలిస్తే, ల్యాప్‌టాప్ సరిపోతుంది. Permission prompt ఒక నిజమైన నియంత్రణ. సర్వర్‌పై Claude Code ను సురక్షితంగా నడపడం ప్రతి స్థాయి వాస్తవంగా ఏ చర్యలను నిరోధిస్తుందో వివరిస్తుంది. Production credentials ఏవీ లేని ఒకే repository పై మాత్రమే మీరు పనిచేస్తే, నష్టం వ్యాప్తి పరిధి ఇప్పటికే చిన్నదే. Agent sessions తక్కువసేపు ఉండి, మీరు వాటిని పర్యవేక్షిస్తే, exposure window కూడా తక్కువగా ఉంటుంది.

మీరు prompts ను దాటవేసిన క్షణం పరిస్థితి మారుతుంది. 14 August 2026 న auto mode Claude Code యొక్క default గా మారుతుంది కాబట్టి దీనిని ఇప్పుడే పరిగణించాలి. Fresh install ఇక files మార్చే ముందు లేదా commands నడిపే ముందు అడగదు. పర్యవేక్షణ లేని runs, రాత్రంతా నడిచే jobs, అలాగే plan ను approve చేసి అక్కడి నుంచి వెళ్లిపోయే workflows — ఇవన్నీ containment ను నిర్వహిస్తున్న మానవ తనిఖీని తొలగిస్తాయి. అప్పుడు ఆ పని machine చేయాలి. Agent కు మరింత విస్తృతమైన access ఇచ్చే సందర్భాలకూ ఇదే వర్తిస్తుంది. ఉదాహరణకు, ఒకేసారి అనేక repositories పై 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 కు system లోని ప్రతి ఇతర account ను చదవగల సామర్థ్యం ఉంటుంది. sudo లేకుండా agent user ను సృష్టించండి. దాని స్వంత work directory కి మాత్రమే write access ఇవ్వండి. task కు నిజంగా package installation అవసరమైతే, ఇతరులతో share చేసే machine పై root access ఇవ్వడం కంటే agent స్వంతంగా నిర్వహించే మొత్తం machine ను కేటాయించండి.

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

connect చేసేటప్పుడు ssh -A తో మీ SSH agent ను forward చేయండి. private key మీ laptop లోనే ఉంటుంది. Signature requests connection ద్వారా ప్రయాణిస్తాయి. అందువల్ల ssh -T git@github.com authenticate అవుతుంది, అలాగే server పై private key లేకుండానే git push పనిచేస్తుంది. అయితే మీరు connected గా ఉన్న సమయంలో ఆ server పై root account 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 దాదాపుగా ఉండదు. scripting పనులకు 2 GB RAM తో ప్రారంభించండి. repository containers ను build చేస్తే లేదా గణనీయమైన code ను compile చేస్తే 8 GB కు పెంచండి.

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

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