VPSలో AI agent కోసం headless Chromium ఎలా నడపాలి

మీరు ఏమి నడుపుతున్నారు

VPSలో headless browser అంటే window లేకుండా నడిచే Chromium. దీన్ని వ్యక్తి కాకుండా మీ code నియంత్రిస్తుంది. Serverపై ఇది దీర్ఘకాలం నడిచే process treeగా ఉంటుంది. మీ agent local socket ద్వారా దానితో మాట్లాడుతుంది. దీన్ని install చేయడానికి ఒక command చాలు. ఆ తర్వాతి నిర్వహణే ప్రధాన పని. Browser machine నుంచి వినియోగించగల వనరులకు పరిమితి విధించాలి. దాని control endpoint public internetకు అందుబాటులో లేకుండా చూడాలి.

ఈ guideలో tool ఎంపిక ఇప్పటికే పూర్తయిందని, ఇప్పుడు దాన్ని operate చేయాల్సి ఉందని భావిస్తున్నాం. మీరు ఇంకా crawlers మరియు extractors మధ్య పోల్చి చూస్తుంటే, self-hosted Firecrawl ప్రత్యామ్నాయాలు నుంచి ప్రారంభించి తరువాత ఇక్కడికి రండి. దిగువ సూచనలన్నీ Playwright's Chromiumను ఉపయోగిస్తాయి. Playwright తన browser buildను మరియు dependency installerను స్వయంగా అందిస్తుంది. అందువల్ల అదే commands bare Ubuntu VPSలోనూ containerలోనూ పనిచేస్తాయి. Versions August 2026 నాటికి ప్రస్తుతమైనవి.

అనుమానాలతో కాకుండా dependencies లేకుండా Chromium ను install చేయండి

npm i -D playwright@1.62.0
npx playwright install --with-deps chromium

--with-deps Chromium కు అవసరమైన shared libraries మరియు fonts కోసం apt ను అమలు చేస్తుంది. అవసరమైన సమయంలో root అధికారాలను అడుగుతుంది. Browser build స్వయంగా ఆ command ను అమలు చేసిన user కోసం ~/.cache/ms-playwright లోకి download అవుతుంది. Server పై ఇది ముఖ్యమైన విషయం, ఎందుకంటే service user సాధారణంగా మీరు login అయ్యే user కాదు. sudo npx playwright install-deps chromium తో admin గా system packages ను ఒకసారి install చేయండి. తరువాత ఒకే copy share అయ్యేలా install command మరియు service unit రెండింటిలోనూ PLAYWRIGHT_BROWSERS_PATH=/opt/pw-browsers ను సెట్ చేయండి. Browser కనిపించని service ప్రారంభంలోనే విఫలమవుతుంది. అది శోధించిన path ను message లో చూపిస్తుంది.

Playwright version ను pin చేయండి. ప్రతి release ఒక browser build కు అనుసంధానించబడి ఉంటుంది. అందువల్ల pin చేయని npm update నడుస్తున్న service కింద browser ను మార్చవచ్చు. August 2026 నాటికి Playwright 1.62 ప్రస్తుత version.

Chromium యొక్క రెండు builds ఉన్నాయి. అవి ఒకే program కావు. Default download headless shell. ఇది headless mode లో మాత్రమే నడిచే చిన్న binary. npx playwright install --with-deps --only-shell దానినే మాత్రమే install చేస్తుంది. పూర్తి browser ను chromium channel తో పొందుతారు. Playwright browser documentation దీనిని "the real Chrome browser, and is thus more authentic, reliable, and offers more features" అని పేర్కొంటుంది. పెద్ద పరిమాణంలో fetching చేయడానికి shell ను ఉపయోగించండి. Site ప్రవర్తన భిన్నంగా ఉన్నప్పుడు, కారణాన్ని తెలుసుకోవడానికి full browser ను ఉపయోగించండి.

కంటైనర్‌లో headless browser ఎందుకు crash అవుతుంది

Docker ప్రతి container కు 64 MB /dev/shm ఇస్తుంది. Docker documentation లో ఇది స్పష్టంగా ఉంది: "మీరు size ను పూర్తిగా పేర్కొనకపోతే, system 64m ను ఉపయోగిస్తుంది". Chromium తన process‌ల మధ్య rendered content ను ఈ shared memory area ద్వారా పంపుతుంది. అందువల్ల ఒక భారీ page దీనిని పూర్తిగా నింపగలదు. అప్పుడు renderer process ఆగిపోతుంది. మీ laptop లో సరిగ్గా పనిచేసే page పై కూడా client crashed target ను నివేదిస్తుంది. ఏ మార్పు చేయకముందు container లోపల size ను నిర్ధారించండి.

df -h /dev/shm

ఇక్కడ రెండు సరైన పరిష్కారాలు ఉన్నాయి. అవి ప్రత్యామ్నాయాలు; రెండింటినీ కలిపి ఉపయోగించాల్సిన అవసరం లేదు. --ipc=host container ను host IPC namespace లో ఉంచుతుంది. అందువల్ల అది host యొక్క /dev/shm ను ఉపయోగిస్తుంది. దీని పరిమాణం సాధారణంగా RAM లో సగం ఉంటుంది. Playwright's Docker guide దీనిని సిఫారసు చేస్తుంది, ఎందుకంటే ఇది లేకపోతే "Chromium memory అయిపోవడంతో crash కావచ్చు". దీని ప్రతికూలత ఏమిటంటే container మరియు host మధ్య IPC isolation తొలగిపోతుంది. --shm-size=1g private namespace ను కొనసాగిస్తూ mount పరిమాణాన్ని మాత్రమే పెంచుతుంది.

docker run --rm -it --init --ipc=host --user pwuser mcr.microsoft.com/playwright:v1.62.0-noble /bin/bash

చాలా search results లో కనిపించే సమాధానం --disable-dev-shm-usage flag. కానీ అది వేరే పని చేస్తుంది: ఆ files ను /dev/shm నుంచి temporary directory కి తరలిస్తుంది. /tmp disk పై ఉంటే, crash కు బదులుగా slow rendering మరియు disk writes వస్తాయి. /tmp tmpfs అయితే, data మళ్లీ RAM లోనే ఉంటుంది; అయితే దానికి ఎలాంటి size limit ఉండదు. చిన్న VPS లో browser అధిక RAM వినియోగించడానికి ఇది ఒక కారణం కావచ్చు. బదులుగా /dev/shm పరిమాణాన్ని సరిగ్గా నిర్ణయించండి.

--no-sandbox వాస్తవంగా కలిగించే ఖర్చు

Chromium ప్రతి renderer ను Linux user namespaces పై నిర్మించిన sandbox లో వేరు చేస్తుంది. ఆ sandbox ఒక హానికరమైన పేజీకి, మీ server కు మధ్య సరిహద్దుగా పనిచేస్తుంది. అది ప్రారంభం కాకపోతే Chromium నడవడానికి నిరాకరిస్తుంది. Log లో ఇలాంటి పంక్తి కనిపిస్తుంది:

Failed to move to new namespace: PID namespaces supported, Network namespace supported, but failed: errno = Operation not permitted

సాధారణంగా ఇచ్చే సలహా --no-sandbox. Chromium యొక్క స్వంత security documentation ఈ flag వల్ల కలిగే ప్రభావాన్ని స్పష్టంగా చెబుతుంది: ఈ flag "Chromium యొక్క కీలక security features ను నిలిపివేస్తుంది. Open web ను browse చేసేటప్పుడు దీన్ని ఎప్పుడూ ఉపయోగించకూడదు". Links ను అనుసరించే agent నిర్వచనం ప్రకారం open web ను browse చేస్తుంది. కాబట్టి అసలు కారణాన్ని కనుగొనండి.

దాదాపు ప్రతి సందర్భాన్ని రెండు కారణాలు వివరిస్తాయి. Browser ను root గా నడిపితే sandbox నిలిపివేయబడుతుంది, ఎందుకంటే ఇప్పటికే ఉన్న privileges ను అది తగ్గించుకోలదు. అందుకే Playwright image లో pwuser అనే సాధారణ user ఉంటుంది. Ubuntu 24.04 మరియు తదుపరి versions లో AppArmor, unprivileged user namespaces కు పరిమితులు విధిస్తుంది. Shipped profile ఏదీ కవర్ చేయని path లో Chromium binary ఉంటే, దాని access నిరాకరించబడుతుంది. ~/.cache/ms-playwright కింద Playwright download సరిగ్గా అలాంటి path లో ఉంటుంది. రెండింటినీ పరిశీలించండి:

id -u
sysctl kernel.apparmor_restrict_unprivileged_userns
sudo dmesg | grep -i userns_create

sysctl నుంచి వచ్చిన 1 మరియు apparmor="DENIED" operation="userns_create" ఉన్న kernel line కలిపి కనిపిస్తే రెండవ కారణం నిర్ధారించబడుతుంది. మిగతా box మొత్తానికి restriction కొనసాగుతూనే ఉండేలా, ఆ ఒక్క binary ను /etc/apparmor.d/pw-chromium లో అనుమతించండి:

abi <abi/4.0>,
include <tunables/global>

profile pw-chromium /home/*/.cache/ms-playwright/*/chrome-linux/{chrome,headless_shell} flags=(unconfined) {
  userns,
}

దీన్ని sudo apparmor_parser -r /etc/apparmor.d/pw-chromium తో load చేయండి. Path లో browser revision ఉంటుంది. అందువల్ల ప్రతి Playwright upgrade సమయంలో అది మారుతుంది. పై globs ఆ మార్పులను తట్టుకుంటాయి. ఒక నిర్దిష్ట exact path కు రాసిన profile matching ను నిశ్శబ్దంగా కోల్పోతుంది. సంబంధం లేనట్టుగా కనిపించే update తర్వాత browser మళ్లీ విఫలమవుతుంది.

స్క్రీన్‌షాట్‌లు ఖాళీగా లేదా పెట్టెలతో నిండుగా ఎందుకు వస్తాయి

ఖాళీ స్క్రీన్‌షాట్ లేదా ఖాళీ దీర్ఘచతురస్రాలతో నిండిన స్క్రీన్‌షాట్ సాధారణంగా rendering bug వల్ల కాదు; ఇది font సమస్య. install-deps పనిచేసే ప్రాథమిక font సముదాయాన్ని పొందుతుంది: fonts-liberation, fonts-freefont-ttf, fonts-noto-color-emoji, fonts-unifont, జపనీస్ కోసం fonts-ipafont-gothic, చైనీస్ కోసం fonts-wqy-zenhei, థాయ్ కోసం fonts-tlwg-loma-otf. ఆ సముదాయంలో Noto CJK లేదు. అందువల్ల కొరియన్ మరియు మరికొన్ని scriptలు fontconfig కనుగొన్న fontకు fallback అవుతాయి. ఊహించకుండా fontconfig ను అడగండి:

fc-match "sans-serif:lang=ko"
fc-match "sans-serif:lang=ar"
fc-list | wc -l

మీకు అవసరమైన ఏదైనా భాష unifont కు resolve అయితే లేదా నిజమైన glyphలు లేని fallbackకు resolve అయితే, fonts-noto-core మరియు fonts-noto-cjk ను install చేసి, తరువాత మళ్లీ తనిఖీ చేయండి. Fontconfig తన ఫలితాలను cache చేస్తుంది. అందువల్ల fonts install చేసిన తరువాత browser ను restart చేయండి. fonts ఏవీ లేని stripped image ప్రారంభ సమయంలో Fontconfig error: Cannot load default config file ను log చేస్తుంది. అప్పుడు ప్రతి page ఖాళీగా render అవుతుంది.

Locale మరియు time zone fonts‌కు వేరు. అవి page ఎలా కనిపిస్తుందో మాత్రమే కాకుండా, page ఏమి చెబుతుందో కూడా మార్చుతాయి. సాధారణంగా containerలో LANG unsetగా ఉంటుంది, TZ UTCగా ఉంటుంది. అందువల్ల sites Englishలో content అందిస్తాయి, UTC timestampsను చూపిస్తాయి. అలాగే మీ agent reports‌లోని సమయాలు ఆ దేశంలోని వ్యక్తి చూసే సమయాలతో సరిపోలవు. వీటిని machine స్థాయిలో కాకుండా browser context స్థాయిలో సెట్ చేయండి. అప్పుడు ఒకే browserను వేర్వేరు ప్రాంతాల కోసం tasks నిర్వహించడానికి ఉపయోగించవచ్చు.

const context = await browser.newContext({
  locale: 'en-GB',
  timezoneId: 'Europe/Paris',
});

లీకైన browser processes ఎందుకు సర్వర్‌ను swap ఉపయోగించేలా చేస్తాయి

"zombie" అనే పేరు రెండు వేర్వేరు సమస్యలకు ఉపయోగిస్తారు. నిజమైన zombie అనేది పూర్తయిన process. దాని parent process ఎప్పుడూ wait() ను పిలవలేదు. అది PID entry ను మాత్రమే ఉంచుతుంది; మరేమీ ఉంచదు. అందువల్ల అది memoryని వినియోగించదు. Containerలో browser PID 1గా నడిచినప్పుడు ఇటువంటి processes పేరుకుపోతాయి, ఎందుకంటే PID 1కు default reaper ఉండదు. Dockerలోని --init flag దీనినే సరిచేస్తుంది. అది "signals ను forward చేసి processes ను reap చేసే" చిన్న initను నడుపుతుంది. Composeలో దీనికి సమానమైనది init: true.

మీ సర్వర్ swap ఉపయోగించేలా చేసే leak మాత్రం వేరు: ఎవరూ close చేయని live Chromium processes. newContext() మరియు close() మధ్యలో taskలో exception వచ్చినప్పుడు, లేదా controlling scriptను kill చేయడం వల్ల దాని browser tree orphaned అయినప్పుడు ఇది జరుగుతుంది. ప్రతి request కోసం కొత్త browserను launch చేసే code అత్యంత సమస్యాత్మకమైనది. వాటిని లెక్కించండి:

pgrep -c -f 'headless_shell|chrome'
ps -eo pid,ppid,rss,etime,comm --sort=-rss | head -20

Tasks మధ్య ఈ count idle విలువకు తిరిగి రావాలి. ఒక రోజులో అది పెరుగుతూ ఉంటే, పరిష్కారం launch flagsలో కాదు; మీ codeలో ఉంటుంది. finally blockలో contextను close చేయండి, SIGTERM సమయంలో browserను close చేయండి. ఒక browserను నెలరోజులు నడపకుండా, నిర్దిష్ట సంఖ్యలో tasks పూర్తైన తర్వాత దాన్ని మళ్లీ ప్రారంభించండి. systemd కింద stop లేదా restart ఆ unitకు చెందిన cgroupలోని ప్రతిదాన్ని kill చేస్తుంది. అందువల్ల sudo systemctl restart browser.service నమ్మదగిన reset విధానం. Terminal multiplexerలో చేతితో ప్రారంభించిన browserకు ఇలాంటి హామీ ఉండదు. దాని orphan processes session ముగిసిన తర్వాత కూడా కొనసాగుతాయి.

ఒక browser context కు ఎంత RAM అవసరం

ఈ ప్రశ్నను ఖచ్చితంగా అడగాలి. ఎందుకంటే “ఒక browser” అంటే ఒకే process కాదు. Chromium ఒక browser process, ఒక GPU process, utility processes, అలాగే ప్రతి site కు ఒక renderer process నడుపుతుంది. Site isolation వల్ల cross-site iframes కు కూడా ప్రత్యేక renderer అవసరం అవుతుంది. ఒక BrowserContext అదే process tree లో ప్రత్యేక cookie jar మరియు storage area ను కలిగి ఉంటుంది. అందువల్ల రెండవ context కు తక్కువ memory మాత్రమే అవసరం. రెండవ page కు మాత్రం అలా కాదు. అది renderer processes ను ప్రారంభిస్తుంది. ప్రకటనలు ఎక్కువగా ఉన్న page అయితే అనేక processes ను ప్రారంభించవచ్చు.

కాబట్టి మీ స్వంత workload కింద మొత్తం process tree ఉపయోగించే గరిష్ఠ memory ను కొలవాలి. మరొకరి blog లోని సంఖ్య ఇక్కడ ఉపయోగకరం కాదు. మీ agent తెరిచే pages ఆధారంగానే అసలు పరిమాణం నిర్ణయించబడుతుంది. మీరు ఉపయోగించబోయే machine పై, మీరు సందర్శించబోయే sites తో కొలవండి:

sudo systemd-run --unit=browser-probe -p MemoryMax=2G -p MemorySwapMax=0 -p WorkingDirectory=/srv/agent /usr/bin/node worker.js
systemctl status browser-probe

Ubuntu 24.04 లో ఆ output లోని Memory: line unit యొక్క ప్రస్తుత మరియు గరిష్ఠ వినియోగాన్ని చూపుతుంది. Worker ను ఒకేసారి ఒక page తో నడిపి peak విలువను నమోదు చేయండి. తరువాత రెండు pages తెరిచి మళ్లీ కొలవండి. అప్పుడు రెండవ page కు వాస్తవంగా ఎంత memory అవసరమో తెలుస్తుంది. Concurrency ను తరువాత ఇలా లెక్కించవచ్చు: మొత్తం RAM నుంచి మిగతా system కు అవసరమైన memory ను తీసివేయండి. కొన్ని వందల MB headroom ఉంచండి. మిగిలిన మొత్తాన్ని ప్రతి worker కు కొలిచిన peak memory తో భాగించండి. ఈ agent కోసం ఉపయోగించే machine పరిమాణాన్ని నిర్ణయించడానికి agent VPS కు ఎంత RAM మరియు CPU అవసరం చూడండి.

ఆ పరిమితిని రెండు చోట్ల అమలు చేయండి. మీ code లో fixed worker pool లేదా semaphore ఉపయోగించండి. అప్పుడు agent requests అకస్మాత్తుగా పెరిగినప్పుడు కొత్త browsers ప్రారంభం కాకుండా queue లో వేచి ఉంటాయి. OS లో cgroup limit ఉపయోగించండి. అప్పుడు queue లోని bug కారణంగా మొత్తం machine నిలిచిపోదు:

[Service]
MemoryMax=2G
MemorySwapMax=0
TasksMax=512
Restart=always

MemorySwapMax=0 కనిపించేదానికంటే ఎక్కువ ప్రాధాన్యం కలిగి ఉంటుంది. ఇది లేకపోతే cgroup limit చేరినప్పుడు pages ను swap కు తరలిస్తుంది. దాంతో machine నడుస్తూనే ఉంటుంది, కానీ ప్రతి request నెమ్మదిస్తుంది. ఇది స్పష్టమైన failure కంటే నిర్ధారించడం కష్టం. MemorySwapMax=0 ఉన్నప్పుడు kernel ఆ cgroup లోని browser process tree ను terminate చేస్తుంది. systemd unit ను restart చేస్తుంది. అలాగే sshd కొనసాగుతుంది. Compose లోని సమానమైన controls mem_limit, shm_size మరియు init. వీటి గురించి Docker Compose లో memory limits అమర్చడం లో వివరించబడింది.

బ్రౌజర్ endpoint ను public internet కు అందుబాటులో ఉంచవద్దు

Playwright బ్రౌజర్‌ను serverగా నడిపి, మీ agent కు WebSocket URL అందించగలదు:

const { chromium } = require('playwright');
const server = await chromium.launchServer({ port: 3000 });
console.log(server.wsEndpoint());

ఆ endpoint కు login లేదు. Playwright API documentation దీన్ని స్పష్టంగా చెబుతోంది: "wsPath గురించి తెలిసిన ఏ process లేదా web page అయినా (Playwright లో నడుస్తున్న వాటితో సహా) OS user పై నియంత్రణ సాధించగలదు." Default host localhost. ఇది "loopback interface నుంచి మాత్రమే connections స్వీకరిస్తుంది". అయితే 0.0.0.0 వంటి explicit address ను ఇవ్వడం వల్ల "listening port ను చేరగల ఏదైనా దానికి browser RPC బహిర్గతమవుతుంది" అని documentation హెచ్చరిస్తోంది. Chrome యొక్క స్వంత --remote-debugging-port ఇంకా ప్రమాదకరం. DevTools protocol కు ఎలాంటి authentication లేదు. ఇది పూర్తిగా loopback కు bind అయి ఉండటంపై ఆధారపడుతుంది.

మీరు వాస్తవంగా ఏవి publish చేశారో తనిఖీ చేయండి. VPS నుంచే కాకుండా రెండవ machine నుంచి కూడా తనిఖీ చేయండి:

ss -ltnp

0.0.0.0 కు bind అయిన browser port పై ఉన్న ఏదైనా finding గా పరిగణించాలి. చాలా providers తమ control panel లో ప్రత్యేక network firewall ను అమలు చేస్తారని గుర్తుంచుకోండి. మీ ufw rules కు ఆ firewall గురించి ఏమీ తెలియదు. SSH tunnel లేదా private VPN ద్వారా మరో machine నుంచి endpoint ను చేరండి:

ssh -N -L 3000:127.0.0.1:3000 you@your-vps

ఇక్కడి ప్రమాదం browser సమయాన్ని ఎవరైనా దొంగిలించడంకంటే పెద్దది. మీరు నియంత్రించగల browser మీ network లోనే ఉన్న request-forgery machine వంటిది. ఆ socket ను చేరగల వ్యక్తి http://127.0.0.1:8080, మీ database admin page లేదా cloud metadata address 169.254.169.254 ను fetch చేయించి, page నుంచి response ను చదవగలడు. ఆ request VPS నుంచే వచ్చిందని మీ firewall చూస్తుంది. అందువల్ల అది అనుమతించబడుతుంది. ఈ control endpoint ను ఆ box పై shell access కు సమానంగా పరిగణించండి.

MCP servers కూడా ఇదే విధంగా పనిచేస్తాయి. npx @playwright/mcp@latest --headless --port 8931 localhost పై HTTP ద్వారా సేవ అందిస్తుంది. స్థానిక tool ను public tool గా మార్చే flag --host 0.0.0.0. Playwright MCP "భద్రతా సరిహద్దు కాదు" అని project README స్పష్టంగా చెబుతోంది. Port ను loopback పై ఉంచి, అదే tunnel ద్వారా agent దాన్ని చేరేలా చేయండి.

మీ agent చదివే పేజీలలో నమ్మకంలేని input ఉంటుంది

Open web ను browse చేసే agent, అపరిచితులు రాసిన text ను మీ instructions ను కూడా కలిగి ఉన్న model కు అందిస్తుంది. ఒక page ఆ model ను ఉద్దేశించి text కలిగి ఉండవచ్చు. ఆ text task ను వదిలేయమని, tool ను call చేయమని లేదా URL కు data ను post చేయమని చెప్పవచ్చు. Model రెండింటినీ text గానే స్వీకరిస్తుంది. అందువల్ల page లోని మాటలను మీ instructions నుంచి నమ్మదగిన విధంగా వేరు చేయలేరు. Hostile page కు ఉపయోగించుకోగల అవకాశాలు చాలా తక్కువగా ఉండేలా setup ను రూపొందించండి.

• Browser ను ప్రత్యేక OS user కింద run చేయండి. ఆ user వద్ద SSH keys ఉండకూడదు. దాని environment లో cloud credentials కూడా ఉండకూడదు.
• ప్రతి task కు కొత్త context ను ఉపయోగించండి. Playwright MCP తో --isolated చేయండి. అందువల్ల ఒక site లోని session తదుపరి page కు అందుబాటులో ఉండదు.
• Job కు అనుమతి ఉన్నప్పుడు origin allowlist ను నిర్వహించండి. Playwright MCP, --allowed-origins మరియు --blocked-origins ను semicolon-separated lists గా స్వీకరిస్తుంది.
• Mail పంపడం లేదా డబ్బు ఖర్చు చేయడం వంటి state ను మార్చే ప్రతి action కు ముందు human step ను తప్పనిసరి చేయండి.

ఇంకా మంచిది, మొత్తం browser ను మీరు తొలగించి మళ్లీ build చేయగల machine పై ఉంచండి. ఇది disposable VM లో coding agents ను run చేయడం వెనుక ఉన్న అదే కారణం. Agent యొక్క అసలు పని open-ended browsing కాకుండా search అయితే, full browser కంటే narrower tool సురక్షితం. మీ స్వంత SearXNG ఆధారంగా పనిచేసే search skill hostile page ను ఎప్పుడూ load చేయకుండా results ను అందిస్తుంది.

FAQ

Chromium Docker లో crash అవుతుంది, కానీ అదే VPSలో నేరుగా సరిగ్గా ఎందుకు పనిచేస్తుంది?

Container‌కు డిఫాల్ట్‌గా 64 MB /dev/shm లభిస్తుంది. Hostలో అది చాలా పెద్దదిగా ఉంటుంది. Chromium render చేసిన content‌ను ఆ shared memory area ద్వారా పంపుతుంది. అందువల్ల heavy page దాన్ని పూర్తిగా నింపితే renderer ఆగిపోతుంది. నిర్ధారించడానికి containerలో df -h /dev/shm అమలు చేయండి. తరువాత host యొక్క shared memoryని ఉపయోగించే --ipc=host తో లేదా container స్వంత shared memory పరిమాణాన్ని పెంచే --shm-size=1g తో ప్రారంభించండి. --disable-dev-shm-usage సమస్యను /tmp కు మాత్రమే తరలిస్తుంది.

VPSలో మరేమీ నడవకపోతే --no-sandbox సురక్షితమేనా?

కాదు. హానికరమైన page మిగతా machineను చేరకుండా sandbox నిరోధిస్తుంది. Chromium documentation ప్రకారం, ఈ flag "Chromium యొక్క కీలక భద్రతా లక్షణాలను నిలిపివేస్తుంది. Open webను browse చేస్తున్నప్పుడు దీన్ని ఎప్పుడూ ఉపయోగించకూడదు". Linksను అనుసరించే agent open webను browse చేస్తుంది. బదులుగా కారణాన్ని పరిష్కరించండి. Browserను rootగా నడపవద్దు. Ubuntu 24.04లో browser binary pathకు userns, కలిగిన AppArmor profileను జోడించండి. దీంతో ఆ ఒక్క programకు మాత్రమే unprivileged user namespaces అనుమతించబడతాయి.

చిన్న VPSలో ఎన్ని browsers నడపగలను?

ఒక సంఖ్యను నకలు చేయకుండా కొలవండి. Chromium ప్రతి siteకు ఒక renderer processను ప్రారంభిస్తుంది. అందువల్ల సమాధానం మీరు తెరిచే pagesపై ఆధారపడి ఉంటుంది. MemoryMax సెట్ చేసి, systemd-run కింద ఒక workerను నడపండి. systemctl status లోని Memory: line నుంచి peakను చదవండి. తరువాత మీ free RAMను ఆ peakతో భాగించి headroom ఉంచండి. ఈ పరిమితిని రెండుసార్లు అమలు చేయండి: మీ codeలో queueతో మరియు unit fileలో MemoryMax తో. దీంతో requests ఒక్కసారిగా పెరిగినప్పుడు machine swapకు వెళ్లకుండా వేచి ఉంటాయి.

నా agent మరో machine నుంచి browserకు connect అవుతుందా?

అవును. కానీ portను ఎప్పుడూ 0.0.0.0 కు bind చేయవద్దు. Playwright server endpoint మరియు Chrome DevTools port రెండూ వాటిని చేరగల ఏ clientనైనా password లేకుండా అంగీకరిస్తాయి. Listenerను 127.0.0.1 పై ఉంచి, connectionను SSH tunnel లేదా private VPN ద్వారా పంపండి. Serverపై ss -ltnp తో నిర్ధారించండి. బయట నుంచి port check కూడా చేయండి. మీ providerకు ఉన్న ప్రత్యేక network firewallను కూడా పరిశీలించండి.

Page స్పష్టంగా load అయినప్పటికీ నా screenshots blankగా ఎందుకు ఉంటాయి?

Fonts లేవు. Page scriptకు సరిపోయే font లేకపోతే text ఖాళీ boxesగా render అవుతుంది లేదా అసలు కనిపించదు. అందువల్ల image-light page blankగా కనిపిస్తుంది. మీరు scrape చేసే ప్రతి languageకు fc-match "sans-serif:lang=ko" అమలు చేయండి. ఫలితం generic fallback అయితే fonts-noto-core మరియు fonts-noto-cjk install చేయండి. తరువాత browserను restart చేయండి, తద్వారా fontconfig తన cacheను మళ్లీ load చేస్తుంది. Fonts ఏవీ లేని container startup సమయంలో Fontconfig error: Cannot load default config file ను log చేస్తుంది.