Coding agent కోసం పారవేయగల VM ఎలా ఏర్పాటు చేయాలి

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

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

ఇదే మొత్తం వాదన. ఇది probability గురించి కాకుండా asymmetry గురించి. జాగ్రత్తగా పనిచేసే agent, జాగ్రత్తగా ఉపయోగించే ల్యాప్‌టాప్‌లో, దాదాపు ప్రతిసారీ సమస్య లేకుండా పనిచేస్తుంది. కానీ ఒక్కసారి సమస్య వచ్చినప్పుడు, దాని ఖర్చు చెడు commit తో ముగియదు. మీ వద్ద backup ఉంటే, దానితో restore చేయాల్సి వస్తుంది.

దాని ప్రభావ పరిధి గురించి వాదించే ముందు దానిని స్పష్టంగా నిర్వచించండి

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

అందులో ~/.ssh/id_ed25519 కూడా ఉంటుంది. మీరు passphrase టైప్ చేయడం విసిగిపోయినందువల్ల అది సాధారణంగా unencrypted గా ఉంటుంది. అందులో ~/.aws/credentials మరియు ~/.config/gh/hosts.yml కూడా ఉంటాయి. అవి ఉద్దేశపూర్వకంగానే plain text రూపంలో ఉంటాయి. ~/code కింద ఉన్న ప్రతి sibling repository కూడా అందులో ఉంటుంది. స్థానిక 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కు నెలకు కొన్ని డాలర్లు ఖర్చవుతాయి. డెవలపర్ laptopను పునరుద్ధరించడానికి ఒక రోజు పడుతుంది. వెంటనే సమస్యను గుర్తించి, backup ఉన్న పరిస్థితి అయితే అది మంచి సందర్భం.

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

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

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

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

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

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ను పంచుకుంటుంది. కాబట్టి kernel bug ద్వారా బయటకు వచ్చే మార్గం ఉండవచ్చు. మీరు --privilegedను జోడించినప్పుడు లేదా agent "Dockerను ఉపయోగించేందుకు" /var/run/docker.sockను mount చేసినప్పుడు boundary తొలగిపోతుంది. Docker socketను containerలోకి mount చేయడం అంటే, ఆ containerకు hostపై root access ఇచ్చినట్లే.

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

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

ముందుగా భద్రపరచిన server నుంచి ప్రారంభించండి. కొత్త 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తో ప్రవేశిస్తారు. agentను ఉద్దేశపూర్వకంగా sudo group‌లో చేర్చలేదని గమనించండి. sudo ఉన్న agent‌కు root ప్రాప్యత ఉంటుంది. root ఇతర వినియోగదారుల files అన్నింటినీ చదవగలదు. అందువల్ల మీరు ఇప్పుడే ఏర్పాటు చేసిన వేర్పాటు కేవలం పేరుకే మిగులుతుంది. Agent‌కు నిజంగా packages install చేయాల్సి వస్తే, దానికి shared server‌లో sudo ఇవ్వడం కంటే, అది స్వంతంగా నిర్వహించే మొత్తం 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‌ను ఆ యంత్రంలోకి కాపీ చేస్తే, తాత్కాలిక యంత్రం ఉపయోగించే ఉద్దేశమే నెరవేరదు. నియమం సులభం: ఆ యంత్రంలో ఈ రోజు మధ్యాహ్నం మార్చాల్సి వచ్చినా మీరు అభ్యంతరం పడే ఏ credential కూడా ఉండకూడదు.

git కోసం, key‌ను కాపీ చేయకుండా మీ SSH agent‌ను forward చేయండి. private key మీ laptop‌లోనే ఉంటుంది. signature అభ్యర్థనలు మాత్రమే 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తో నిల్వ చేయండి. యంత్రాన్ని తొలగించినప్పుడు, ఆ key లీక్ అయిందేమో అని ఆలోచించకుండా దాన్ని revoke చేయండి. ప్రతి key‌కు model ఖర్చును స్పష్టంగా చూపించడం వల్ల VPSలో AI agent ఖర్చు నియంత్రణలోని సంఖ్యలు కూడా అంచనా వేయగలిగేలా ఉంటాయి.

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

ఫైల్‌సిస్టమ్ వేరుచేయడం పరిమితిలో సగం మాత్రమే. మిగిలిన సగం అవుట్‌బౌండ్ ట్రాఫిక్: ప్రాసెస్ ఎవరితో కమ్యూనికేట్ చేయగలదో అది. ప్రాసెస్‌ను సృష్టించిన వినియోగదారుడి ఆధారంగా Linux అవుట్‌బౌండ్ ట్రాఫిక్‌ను ఫిల్టర్ చేయగలదు. ఈ విధానానికి ఇది సరిపోతుంది.

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 నియమం అడ్డుకుంటుంది. ఏజెంట్‌గా దీన్ని పరీక్షించండి:

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

ఇది curl: (7) Failed to connect to example.com port 80: Connection refusedతో విఫలమవ్వాలి. కారణం, reject నియమం కనెక్షన్ నిలిచిపోకుండా వెంటనే సమాధానం ఇస్తుంది. అదే host‌కు చేసిన HTTPS అభ్యర్థన ఇంకా విజయవంతం కావాలి.

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

పనుల మధ్య శుభ్రమైన స్థితికి రీసెట్ చేయండి

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

సరళమైన మార్గం ప్రతి పనికి కొత్త 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ను localగా దాచుకోకుండా push చేయడం దీనికి అర్థం. Machineలో మీరు కోల్పోవడం ఇష్టపడని ఏదైనా మిగిలితే, VPSలో restic backups ఉపయోగించి సరిగ్గా backup చేయండి. నాశనం చేయగల machine ఉపయోగకరంగా ఉండాలంటే, దాన్ని నాశనం చేయడం నిజంగా ఎలాంటి ఇబ్బందీ లేకుండా జరగాలి.

అనేక servers కోసం చెల్లించకుండా పలు isolated environments కావాలంటే, ఒక పెద్ద VPS నేరుగా guest VMsను host చేయగలదు. VPSలో Nested virtualisation ఇది ఎలా పనిచేస్తుందో, అలాగే మీ provider దీనిని అనుమతిస్తుందో ఎలా తనిఖీ చేయాలో వివరిస్తుంది.

ల్యాప్‌టాప్‌ను జాగ్రత్తగా ఉపయోగించడం నిజంగా సరైన సందర్భం

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

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

మీరు prompts‌ను దాటవేయడం ప్రారంభించిన వెంటనే సమాధానం మారుతుంది. పర్యవేక్షణ లేని runs, రాత్రంతా నడిచే jobs, అలాగే plan‌ను approve చేసి అక్కడి నుంచి వెళ్లిపోయే workflow‌లు containment‌ను నిర్వహిస్తున్న మానవ తనిఖీని తొలగిస్తాయి. అప్పుడు ఆ పనిని machine చేయాలి. ఒకేసారి అనేక repositoriesపై VPS‌లో coding agent‌ను అమలు చేయడం వంటి agent పరిధిని పెంచే ఏ చర్యకైనా ఇదే వర్తిస్తుంది.

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

FAQ

Coding agent కోసం container తగినంత వేరుపాటును అందిస్తుందా?

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

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

లేదు. దానికి sudo ఇవ్వడం ద్వారా మీరు ఏర్పాటు చేసిన isolation తొలగిపోతుంది. కారణం root కు ఆ machine లోని ప్రతి ఇతర account ను చదివే అవకాశం ఉంటుంది. sudo లేకుండా agent user ను సృష్టించండి. దాని స్వంత work directory కి మాత్రమే write access ఇవ్వండి. Package installation నిజంగా అవసరమైతే, ఇతరులతో పంచుకునే machine పై root access ఇవ్వడం బదులు, agent స్వంతంగా నిర్వహించే పూర్తి machine ను ఇవ్వండి.

Server పై నా SSH key ఉంచకుండా 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 పనిచేస్తుంది. అయితే మీరు connect అయి ఉన్న సమయంలో ఆ server పై root, forwarded socket ను ఉపయోగించగలదు. కాబట్టి ఇతరులతో పంచుకునే machine పై repository-scoped deploy key ను ఉపయోగించండి.

Agent కు ఎంత పరిమాణం గల VPS అవసరం?

Agent పని ప్రధానంగా files ను edit చేయడం, builds ను run చేయడం, tests ను run చేయడం వంటివి. అందువల్ల machine పరిమాణాన్ని model కోసం కాకుండా build కోసం నిర్ణయించండి. Hosted model, provider యొక్క hardware పై నడుస్తుంది. దీనివల్ల network traffic పెరుగుతుంది, కానీ local load దాదాపు ఉండదు. Scripting పనులకు 2 GB RAM తో ప్రారంభించండి. Repository containers ను build చేస్తే లేదా గణనీయమైన code ను compile చేస్తే 8 GB కి పెంచండి.

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

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