Self-hosted Firecrawl ప్రత్యామ్నాయాలు: ఉత్తమమైనవి ఇవే

Self-hosted Firecrawl ప్రత్యామ్నాయం చేయాల్సిన పనులు

Self-hosted Firecrawl ప్రత్యామ్నాయానికి ఒకే ఒక పని ఉంటుంది: ఒక URLను తీసుకుని, దానిని ఏజెంట్ చదవగలిగేలా శుభ్రమైన markdown ఫార్మాట్‌లోకి మార్చి అందించడం. హోస్ట్ చేసిన APIలు ప్రతి పేజీకి ఛార్జ్ చేస్తాయి, కాబట్టి మీ ఏజెంట్ ఎంత ఎక్కువగా అన్వేషిస్తే బిల్లు అంత పెరుగుతుంది. మీరు ఇప్పటికే చెల్లిస్తున్న VPS ద్వారానే ఈ పనిని పూర్తి చేయవచ్చు. ఈ ప్రాజెక్టుల మధ్య ఉన్న ప్రధాన వ్యత్యాసం ఒక్కటే: మీ సర్వర్‌లో headless browser (విండో లేకుండా నడిచే అసలైన బ్రౌజర్ ఇంజిన్) ప్రారంభం కావాలా వద్దా?

ఈ సమాధానంపైనే మెమరీ వినియోగం, ప్రతి పేజీకి అయ్యే ఖర్చు మరియు ఏ పేజీలు ఖాళీగా వస్తాయి అనేది ఆధారపడి ఉంటుంది. ఈ గైడ్ Draco, Hound మరియు self-hosted Firecrawl రిలీజ్‌లను పోల్చి చూస్తుంది, వీటిలో అత్యంత తేలికైన దానిని నిర్దిష్ట వెర్షన్‌లో ఇన్‌స్టాల్ చేస్తుంది మరియు దానిని MCP (model context protocol) ద్వారా ఏజెంట్‌కు అనుసంధానిస్తుంది.

నాలుగు ప్రాజెక్టులు మరియు ప్రతి దాని స్వభావం

Draco అనేది Rust లో వ్రాయబడిన ఒకే binary, ఇది MIT లేదా Apache-2.0 లైసెన్స్‌తో లభిస్తుంది. v0.20.5 విడుదల 16 July 2026న ప్రచురించబడింది. draco scrape <url> ఇది markdown ను stdout కు ప్రింట్ చేస్తుంది. draco serve ఇది Firecrawl ఉపయోగించే 127.0.0.1:3002 పోర్ట్ వద్ద స్పందించే ఒక daemon ను రన్ చేస్తుంది. ఇది ఎటువంటి container image ను అందించదు మరియు బ్రౌజర్‌ను ప్రారంభించదు.

Firecrawl self-hosted అనేది AGPL-3.0 లైసెన్స్ కింద ఉన్న hosted ఉత్పత్తి వెనుక ఉన్న ఇంజిన్. దీని docker-compose.yaml ఏడు సేవలను నిర్వచిస్తుంది: playwright-service, api, redis, rabbitmq, nuq-postgres, foundationdb మరియు foundationdb-init. మీరు ఒక చిన్న distributed system ను రన్ చేసే ఖర్చుతో నిజమైన crawl queue ను పొందుతారు.

Hound అనేది master-fetch రిపోజిటరీలో ఉంటుంది మరియు hound-mcp గా PyPI కి పంపబడుతుంది, ఇది MIT లైసెన్స్ కలిగి ఉంది, 3 August 2026 నాటికి 13.0.1 వెర్షన్‌లో ఉంది. దీనికి Python 3.11 లేదా అంతకంటే కొత్త వెర్షన్ అవసరం. ఇది మొదట ఒక MCP సర్వర్ మరియు తర్వాతే fetcher: ఇది సాధారణ HTTP ని ప్రయత్నిస్తుంది, మరియు సాధారణ fetch బ్లాక్ చేయబడినప్పుడు మాత్రమే Patchright బ్రౌజర్‌ను ప్రారంభిస్తుంది.

Trawl ఇక్కడ ఎందుకు ఉందంటే, ఇతర ప్రాజెక్టుల కోసం వెతికేటప్పుడు ప్రజలు దీనిని చూస్తారు, కానీ ఇది భిన్నమైన పనిని చేస్తుంది. ఇది *arr మీడియా స్టాక్‌లో FlareSolverr కు ప్రత్యామ్నాయంగా, fingerprint-patched Firefox తో JavaScript సవాళ్లను మరియు CAPTCHA లను పరిష్కరిస్తుంది. ఇది markdown ఎక్స్‌ట్రాక్టర్ కాదు. ఈ వ్యత్యాసం మీ ఏజెంట్ స్టాక్‌లో ఇది ఉండాలా వద్దా అని ఎలా నిర్ణయిస్తుందో క్రింది మర్యాదలకు సంబంధించిన విభాగం వివరిస్తుంది.

చిన్న VPS బాక్సులకు బ్రౌజర్ పూల్ ఎందుకు ముగింపుగా మారుతుంది

ప్రతి ఓపెన్ బ్రౌజర్ ట్యాబ్ ఒక ప్రత్యేకమైన రెండరర్ ప్రాసెస్‌ను కలిగి ఉండి, దాని స్వంత DOM (document object model) మరియు JavaScript హీప్‌ను నిర్వహిస్తుంది. కాబట్టి, మెమరీ వినియోగం అనేది రోజుకు ఎన్ని పేజీలను పొందామనే దానిపై కాకుండా, ఒకే సమయంలో ఎన్ని పేజీలు తెరిచి ఉన్నాయనే దానిపై ఆధారపడి పెరుగుతుంది. ఈ ప్రాజెక్టులలో రెండు తమ సొంత compose ఫైళ్లలోనే ఆ ఖర్చును పేర్కొన్నాయి.

[
  {
    "label": "Firecrawl api",
    "memory_limit_gb": 8
  },
  {
    "label": "Firecrawl playwright",
    "memory_limit_gb": 4
  },
  {
    "label": "Hound (browser included)",
    "memory_limit_gb": 3
  }
]

Firecrawl compose ఫైల్ తన api కంటైనర్‌ను 8 GBకి మరియు దాని Playwright కంటైనర్‌ను 4 GBకి పరిమితం చేస్తుంది, అలాగే దానికి సరిపడా swap పరిమితులను కూడా కలిగి ఉంటుంది. Hound యొక్క compose ఫైల్, Chromiumను కలిగి ఉన్న ఒక కంటైనర్ కోసం 3 GBని కేటాయిస్తుంది. ఇవి ప్రాజెక్టులు ఎంచుకున్న గరిష్ట పరిమితులు; ఇవి నిశ్శబ్దంగా ఉన్న సిస్టమ్ కొలతలు కావు, కేవలం ప్రచురించిన గణాంకాలు మాత్రమే. వీటితో పాటు Redis, RabbitMQ, PostgreSQL మరియు FoundationDB లకు కూడా అదనపు మెమరీ అవసరమవుతుంది.

మీ దగ్గర ఉన్న RAM కంటే ఎక్కువ పరిమితిని సెట్ చేయడం వల్ల ఎటువంటి ప్రయోజనం ఉండదు. బాక్స్‌లో మెమరీ అయిపోయినప్పుడు, కెర్నల్ యొక్క out-of-memory killer ఒక ప్రాసెస్‌ను నిలిపివేస్తుంది. దీనివల్ల అప్లికేషన్ లాగ్‌లో ఎటువంటి ఎర్రర్ నమోదు కాకుండానే కంటైనర్ docker compose ps నుండి మాయమవుతుంది. వివరించలేని విధంగా ఏదైనా రీస్టార్ట్ జరిగినప్పుడు dmesg -T | tailని పరిశీలించండి. పూర్తి Firecrawl స్టాక్ కోసం 8 GB మెమరీని బడ్జెట్‌గా ఉంచుకోండి మరియు 4 GBని టెస్ట్-బాక్స్ కోసం కనీస అవసరంగా పరిగణించండి. ప్రతి సర్వీస్‌కు ఈ సంఖ్యలను సెట్ చేయడం గురించి Docker Composeలో మెమరీ పరిమితులు విభాగంలో వివరించబడింది.

బ్రౌజర్‌కు సంబంధించిన మరొక ముఖ్యమైన విషయం చాలా మంది సమయాన్ని వృథా చేస్తుంది. Docker ఒక కంటైనర్‌కు /dev/shm వద్ద 64 MB షేర్డ్ మెమరీని ఇస్తుంది, Chromium తన రెండరర్ బఫర్‌లను అక్కడ ఉంచుతుంది, కాబట్టి భారీ పేజీలను లోడ్ చేసేటప్పుడు అది క్రాష్ అవుతుంది. రెండు బ్రౌజర్ స్టాక్‌లు దీనిని పెంచుతాయి: Hound యొక్క compose ఫైల్‌లో shm_size: "1gb" ఉంటుంది. Playwright చుట్టూ మీరు నిర్మించే ఏదైనా ఇమేజ్‌లో ఆ లైన్‌ను కాపీ చేయండి.

JavaScript-heavy పేజీలలో ఎక్స్‌ట్రాక్షన్ నాణ్యత

స్టాటిక్ HTML, సర్వర్-రెండర్డ్ బ్లాగ్, డాక్యుమెంటేషన్ పేజీ లేదా వార్తా కథనం వంటి వాటిలో, సర్వర్ దాదాపు ఒకే విధమైన markdown ను అందిస్తుంది, కాబట్టి వేగంగా స్పందించేది విజయం సాధిస్తుంది. క్లయింట్-రెండర్డ్ పేజీలలో తేడా స్పష్టంగా కనిపిస్తుంది; ఇక్కడ అందించబడిన HTML కేవలం ఖాళీ షెల్ వలె ఉంటుంది మరియు పేజీ లోడ్ అయిన తర్వాత JavaScript ద్వారా టెక్స్ట్ అందుతుంది.

Draco క్రమానుగత పద్ధతిలో (tiers) పనిచేస్తుంది. Tier 0 మరియు tier 1 ఎటువంటి JavaScript లేకుండానే HTML ను పార్స్ చేస్తాయి. Tier 2 పేజీకి చెందిన స్వంత JavaScript ను in-process V8 isolate లో రన్ చేస్తుంది. ఇది బ్రౌజర్ లేని JavaScript ఇంజిన్; README ప్రకారం, అక్కడ పేజీ కోడ్‌కు హోస్ట్ సామర్థ్యాలను (host capability bindings) యాక్సెస్ చేసే అవకాశం ఉండదు. ఇది బ్రౌజర్ వినియోగించే మెమరీలో కొంత భాగంతోనే అనేక single-page అప్లికేషన్లను కవర్ చేస్తుంది. Draco ముందుకు వెళ్లలేని పరిస్థితి ఎదురైనప్పుడు, draco scrape ఎగ్జిట్ కోడ్ 3, needs_browser తో ముగుస్తుంది. స్క్రిప్ట్‌లలో దీన్ని తనిఖీ చేయండి, ఎందుకంటే సున్నా ఎగ్జిట్ కోడ్‌తో వచ్చే ఖాళీ ఫైల్, ఏజెంట్ యొక్క కాంటెక్స్ట్‌ను నిశ్శబ్దంగా పాడుచేసే వైఫల్యానికి దారితీస్తుంది:

draco scrape https://example.com > page.md
echo "exit=$?"

Firecrawl యొక్క playwright-service నిజమైన Chromium ను ఉపయోగిస్తుంది, కాబట్టి బ్రౌజర్ దేనిని రెండర్ చేస్తుందో అది కూడా అదే చేస్తుంది. అయితే, self-hosted బిల్డ్ అనేది క్లౌడ్ ప్రొడక్ట్ కాదు: డాక్యుమెంటేషన్ ప్రకారం self-hosted ఇన్‌స్టాన్స్‌లకు Fire Engine యాక్సెస్ ఉండదు, కాబట్టి క్లౌడ్ సర్వీస్‌లో ఉండే anti-blocking మరియు IP rotation వంటి ఫీచర్లు ఇందులో ఉండవు, అలాగే /agent మరియు /browser ఎండ్‌పాయింట్లు కూడా సపోర్ట్ చేయబడవు. Hound ఉద్దేశపూర్వకంగానే ఈ రెండింటి మధ్యలో ఉంటుంది. ఇది HTTP ద్వారా డేటాను సేకరిస్తుంది మరియు అభ్యర్థనను బట్టి స్థాయిని పెంచుతుంది (escalates). దీని warm browser ఒక నిర్దిష్ట idle timeout తర్వాత మూసివేయబడుతుంది, కాబట్టి తక్కువ వినియోగం ఉన్న సర్వర్లు సాధారణ స్థితిలోనే ఉంటాయి.

Draco ను పిన్ చేసిన వెర్షన్‌తో ఇన్‌స్టాల్ చేయడం

README ఒకే లైన్ ఇన్‌స్టాలర్‌ను వివరిస్తుంది. దాన్ని షెల్‌కు పైప్ చేసే ముందు అది ఏమి చేస్తుందో చదవండి: ఇది $HOME/.draco/bin/draco లో ఇన్‌స్టాల్ అవుతుంది, ఇది ఎల్లప్పుడూ latest రిలీజ్‌ను తీసుకుంటుంది మరియు ఇది ఎటువంటి సిగ్నేచర్ లేదా హ్యాష్‌ను తనిఖీ చేయదు. సర్వర్‌పై, వెర్షన్‌ను పిన్ చేయండి మరియు డౌన్‌లోడ్‌ను ధృవీకరించండి.

cd /tmp
curl -fsSLO https://github.com/0xchasercat/draco/releases/download/v0.20.5/draco-linux-x86-64.tar.gz
curl -fsSLO https://github.com/0xchasercat/draco/releases/download/v0.20.5/SHA256SUMS
sha256sum --ignore-missing -c SHA256SUMS

అది draco-linux-x86-64.tar.gz: OK ను ప్రింట్ చేస్తుంది. FAILED లైన్ అంటే మీ వద్ద ఉన్న బైట్లు ప్రాజెక్ట్ ప్రచురించిన బైట్లు కావు, కాబట్టి వాటిని తొలగించి మళ్ళీ ప్రారంభించండి.

mkdir -p draco-v0.20.5
tar -xzf draco-linux-x86-64.tar.gz -C draco-v0.20.5
sudo install -m 755 "$(find draco-v0.20.5 -type f -name draco | head -n1)" /usr/local/bin/draco
draco scrape https://example.com

చివరి కమాండ్ ఉదాహరణ పేజీని ఒక సెకను కంటే తక్కువ సమయంలో మార్క్‌డౌన్‌గా ప్రింట్ చేస్తుంది. find అనేది అలంకరణ కాదు: ఆర్కైవ్ లేఅవుట్ ప్రాజెక్ట్ యొక్క పబ్లిక్ కాంట్రాక్టులో భాగం కాదు, మరియు అధికారిక ఇన్‌స్టాలర్ బైనరీని అదే విధంగా గుర్తిస్తుంది.

డెమన్‌ను మీ లాగిన్ యూజర్‌కు బదులుగా దాని స్వంత ఖాతా కింద రన్ చేయండి. /etc/systemd/system/draco.service ను రాయండి:

[Unit]
Description=Draco fetch daemon
After=network-online.target
Wants=network-online.target

[Service]
User=draco
ExecStart=/usr/local/bin/draco serve --host 127.0.0.1 --port 3002 --max-concurrency 4
Restart=on-failure
NoNewPrivileges=true
ProtectSystem=strict
ProtectHome=true
PrivateTmp=true

[Install]
WantedBy=multi-user.target

sudo useradd --system --no-create-home --shell /usr/sbin/nologin draco
sudo systemctl daemon-reload
sudo systemctl enable --now draco
curl -s http://127.0.0.1:3002/health

డెమన్ వింటున్న వెంటనే /health సమాధానం ఇస్తుంది. Connection refused అంటే అది వినడం లేదని అర్థం, కాబట్టి journalctl -u draco -n 50 చదవండి. సాధారణ కారణం మరొక ప్రాసెస్ ఇప్పటికే 3002ని కలిగి ఉండటం, ఎందుకంటే అది Firecrawl యొక్క డిఫాల్ట్ పోర్ట్ కూడా, మరియు --port ఏదో ఒకదాన్ని మారుస్తుంది. యూనిట్ ఫైళ్ల గురించి మరింత లోతుగా: systemd service units and timers.

ఇప్పుడు మీ ఏజెంట్ చేసే విధంగా ఫెచ్ చేయండి:

curl -X POST http://127.0.0.1:3002/v1/scrape \
  -H 'content-type: application/json' \
  -d '{"url": "https://example.com", "formats": ["markdown"]}'

Fetch daemon ను పబ్లిక్ ఇంటర్నెట్‌కు దూరంగా ఉంచండి

Authentication లేని fetch API ఒక open proxy లాంటిది. మీ పోర్ట్‌ను యాక్సెస్ చేయగల ఎవరైనా మీ IP అడ్రస్ ద్వారా ఏ URL నైనా రిక్వెస్ట్ చేసేలా సర్వర్‌ను వాడుకోవచ్చు. దీనివల్ల వచ్చే abuse reports వారికి కాకుండా మీ ప్రొవైడర్‌కు వెళ్తాయి. Draco డాక్యుమెంటేషన్‌లో పేర్కొన్న serve ఫ్లాగ్‌లలో API key సదుపాయం లేదు, కాబట్టి నెట్‌వర్క్ స్థాయిలోనే రక్షణ కల్పించాలి. Agent అదే సర్వర్‌లో నడుస్తున్నప్పుడు డిఫాల్ట్ 127.0.0.1 బైండింగ్‌ను అలాగే ఉంచండి. Agent వేరే చోట ఉన్నప్పుడు, రెండు చివరలను ఒక private tunnel లో ఉంచండి; సాధారణంగా మీరు స్వయంగా హోస్ట్ చేసే WireGuard VPN దీనికి సరైన పరిష్కారం. అప్పుడు 0.0.0.0 కు బదులుగా tunnel అడ్రస్‌కు బైండ్ చేయండి. ఆ తర్వాత, పబ్లిక్ IP నుండి ఎటువంటి స్పందన రావడం లేదని వేరే మెషీన్ నుండి నిర్ధారించుకోండి. ufw firewall ప్రాథమిక అంశాలు మరియు least privilege యూజర్ అకౌంట్లు ఈ భద్రతా చర్యలలోని రెండు ముఖ్యమైన భాగాలను వివరిస్తాయి.

మీ ఏజెంట్ కోడ్ మారుతుందా? ఆచరణలో API అనుకూలత

Draco, Firecrawl v1 రూట్‌లైన /v1/scrape, /v1/map, /v1/crawl, /v1/batch/scrape మరియు /v1/search లకు సమాధానమిస్తుంది. దీని README ప్రకారం, తెలియని ఫీల్డ్‌లను అంగీకరించి విస్మరిస్తుంది. ఇప్పటికే /v1/scrape కి పోస్ట్ చేసే ఏజెంట్‌కు కొత్త base URL తప్ప మరేమీ అవసరం లేదు. అవతలి వైపు ఏమి మారిందో గమనించండి: Firecrawl యొక్క స్వంత self-hosting పేజీ ఇప్పుడు /v2/crawl తో పరీక్షిస్తోంది. ప్రస్తుత SDKలు v2 లో పనిచేస్తాయి, కాబట్టి Draco కి పాయింట్ చేసిన v2 క్లయింట్, Draco ప్రచురించని రూట్ కోసం అడుగుతుంది. మీరు ఏజెంట్ కోడ్‌ను ఎడిట్ చేసే ముందు ప్రతి కాల్‌ను curl తో పరీక్షించండి. కేవలం status code ను మాత్రమే కాకుండా JSON body ని చదవండి, ఎందుకంటే ఈ ఇంప్లిమెంటేషన్లలో ఫీల్డ్ పేర్లు వేర్వేరుగా ఉండే అవకాశం ఉంది.

Robots.txt, rate limits, మరియు మీరు పాటించాల్సిన పరిమితులు

Draco డిఫాల్ట్‌గా robots.txt ని చదువుతుంది, మరియు --ignore-robots దానిని నిలిపివేస్తుంది. Firecrawl కూడా అదే డిఫాల్ట్ పద్ధతిని అనుసరిస్తుంది. ఈ రెండింటినీ మార్చవద్దు. ఆ తర్వాత మీ స్వంత వేగాన్ని సెట్ చేసుకోండి: --delay అభ్యర్థనల మధ్య మిల్లీసెకన్లను నిర్ణయిస్తుంది మరియు --max-concurrency సమాంతర పనులను (parallel jobs) పరిమితం చేస్తుంది, దీనికి daemon డిఫాల్ట్ విలువ 8. షేర్డ్ VPS లింక్‌పై 2 నుండి 4 వరకు ఉంచడం మంచిది, ఇది మొత్తం మీద నెమ్మదిగా ఏమీ ఉండదు. ఎందుకంటే ఒక సైట్ మిమ్మల్ని rate limit చేయడం మొదలుపెడితే, మీరు పొదుపు చేసిన concurrency కంటే ఎక్కువ సమయం వృథా అవుతుంది. మీరు సేకరించిన డేటాను cache చేయండి, తద్వారా రెండవసారి ఏజెంట్ రన్ అయినప్పుడు మూల సైట్‌కు ఎటువంటి భారం ఉండదు. AI ఏజెంట్ ఖర్చులను నియంత్రించడం అనే అంశంలో ఇది అత్యంత తక్కువ ఖర్చుతో కూడిన మార్గం.

Challenge walls అనేది ఒక ప్రత్యేక అంశం, మరియు Trawl దీని కోసమే రూపొందించబడింది: Cloudflare Turnstile, reCAPTCHA, hCaptcha మరియు GeeTest. ఒక challenge wall అంటే ఒక సైట్ ఆటోమేటెడ్ ట్రాఫిక్‌ను తిరస్కరిస్తోందని అర్థం. దీన్ని అధిగమించడానికి ప్రయత్నించడం ఆ సైట్ యొక్క ఉపయోగ నిబంధనలకు విరుద్ధం, కొన్ని చోట్ల చట్టవిరుద్ధం కూడా. కాబట్టి, ఈ గైడ్ కేవలం fetching infrastructure వరకు మాత్రమే పరిమితం చేయబడింది. ఒక wall ను దాటడానికి ఉపయోగించే పద్ధతులనే సైట్ యజమానులు గమనించి బ్లాక్ చేస్తారు, దీనివల్ల వాటిపై ఆధారపడిన పైప్‌లైన్ అస్థిరంగా మారడమే కాకుండా, అది మర్యాదపూర్వకమైన పద్ధతి కూడా కాదు. ఒక మూల సమాచారం మీకు అంత ముఖ్యమైనదైతే, దాని RSS feed, public API, లేదా bulk export కోసం చూడండి. వీటిని నిర్వహించడం తక్కువ ఖర్చుతో కూడుకున్నది మరియు wall మారినప్పుడు ఇవి పాడైపోవు.

MCP ద్వారా ఏజెంట్‌కు అనుసంధానించడం

MCP (model context protocol) అనేది ఒక ఏజెంట్ టూల్‌ను పిలవడానికి ఉపయోగించే ఇంటర్‌ఫేస్. Draco అదే బైనరీలో, stdio ద్వారా MCP సర్వర్‌ను కలిగి ఉంటుంది:

{ "mcpServers": { "draco": { "command": "draco", "args": ["mcp"] } } }

అప్పుడు ఆ టూల్స్ ఏజెంట్‌కు draco_scrape, draco_search మరియు draco_interact_* సెట్‌గా కనిపిస్తాయి. ఏజెంట్ ప్రాసెస్ మరియు బైనరీ ఒకే మెషీన్‌పై ఉన్నప్పుడు మాత్రమే Stdio పనిచేస్తుంది, ఎందుకంటే దీని రవాణా (transport) ఆ ప్రాసెస్ యొక్క స్టాండర్డ్ ఇన్‌పుట్ ద్వారా జరుగుతుంది. మరొక హోస్ట్‌లోని ఏజెంట్ కోసం, Hound బదులుగా HTTP ద్వారా MCPని అందిస్తుంది: hound --http --host 127.0.0.1 --port 8765 అనేది http://127.0.0.1:8765/mcp వద్ద ఒక ఎండ్‌పాయింట్‌ను ప్రచురిస్తుంది, దీనిని మీరు టన్నెల్ ద్వారా చేరుకోవచ్చు. రవాణా ఎంపికలు మరియు వేటిని బహిర్గతం చేయాలనే వివరాలు VPSపై MCP సర్వర్లను రన్ చేయడంలో ఉన్నాయి.

సెర్చ్‌తో జతలను పొందడం. కేవలం డేటాను పొందగల ఏజెంట్, మీరు URLలను అందించే వరకు వేచి ఉంటుంది. సెల్ఫ్-హోస్టెడ్ SearXNG సెర్చ్ ఇన్‌స్టాన్స్ను జోడించండి, అప్పుడు అది స్వయంగా వాటిని కనుగొనగలదు; ఇది SearXNGపై నిర్మించిన బ్రౌజర్ సెర్చ్ స్కిల్ మాదిరిగానే ఉంటుంది. డెమోన్ సిద్ధమైన తర్వాత, మీరు రన్ చేసే సెల్ఫ్-హోస్టెడ్ AI ఏజెంట్లలో దేనికైనా ఇది ఒక భాగస్వామ్య సేవగా పనిచేస్తుంది.

FAQ

AI ఏజెంట్ కోసం పేజీలను పొందడానికి నాకు headless browser అవసరమా?

చాలా పేజీలకు అవసరం లేదు. సర్వర్-రెండర్ చేయబడిన డాక్యుమెంటేషన్, బ్లాగులు మరియు వార్తా కథనాలు సాధారణ HTTP fetch మరియు HTML-to-markdown మార్పిడి ద్వారా పూర్తి సమాచారాన్ని అందిస్తాయి. ప్రాజెక్ట్ గణాంకాల ప్రకారం, Draco తన తక్కువ స్థాయిలలో బ్రౌజర్ అవసరం లేకుండానే పేజీకి సుమారు 300 ms లో ఈ పనిని పూర్తి చేస్తుంది. క్లయింట్-రెండర్ చేయబడిన అప్లికేషన్లలో, డెలివరీ చేయబడిన HTML ఖాళీగా ఉంటుంది కాబట్టి, అక్కడ మాత్రమే బ్రౌజర్ మెమరీ అవసరమవుతుంది. Draco యొక్క V8 isolate అటువంటి మధ్యస్థ అవసరాలను బ్రౌజర్ ప్రాసెస్ లేకుండానే తీరుస్తుంది, ఒకవేళ సాధ్యం కాకపోతే అది needs_browser కోడ్‌తో నిష్క్రమిస్తుంది.

VPSలో self-hosted Firecrawl నడపడానికి ఎంత RAM అవసరం?

దీని compose ఫైల్ api కంటైనర్‌పై 8 GB పరిమితిని మరియు Playwright కంటైనర్‌పై 4 GB పరిమితిని సెట్ చేస్తుంది. అదే stack లో Redis, RabbitMQ, PostgreSQL మరియు FoundationDB కూడా ప్రారంభమవుతాయి. కాబట్టి 8 GB RAM ప్లాన్ చేసుకోండి. 2 GB RAM ఉన్న సర్వర్‌లో లోడ్ పెరిగినప్పుడు kernel out-of-memory killer కంటైనర్లను తొలగిస్తుంది. దీనికి మొదటి సంకేతం docker compose ps లో కంటైనర్ రీస్టార్ట్ అవ్వడం, అప్లికేషన్ లాగ్‌లో ఎటువంటి ఉపయోగకరమైన సమాచారం ఉండదు. కాబట్టి dmesg -T | tail తో దీన్ని నిర్ధారించుకోండి.

Firecrawl API కి Draco ప్రత్యామ్నాయంగా పనిచేస్తుందా?

v1 ఎండ్‌పాయింట్ల విషయానికి వస్తే ఇది దాదాపు సమానంగా ఉంటుంది. ఇది /v1/scrape, /v1/map, /v1/crawl, /v1/batch/scrape మరియు /v1/search లను అందిస్తుంది. ఇది తనకు తెలియని రిక్వెస్ట్ ఫీల్డ్‌లను విస్మరిస్తుంది, కాబట్టి Firecrawl v1 కోసం రాసిన క్లయింట్ సాధారణంగా కొత్త base URL ని మాత్రమే మార్చుకోవాల్సి ఉంటుంది. ఇది హోస్ట్ చేయబడిన ఉత్పత్తి కాదు: దీని వెనుక ఎటువంటి managed proxy pool ఉండదు మరియు Firecrawl యొక్క కొత్త v2 రూట్లు ఇందులో లేవు. మీ ఏజెంట్ చేసే ప్రతి కాల్‌ను ముందుగా curl తో సరిచూసుకోండి.

స్క్రాపర్‌ను self-host చేయడం అంటే robots.txt ని విస్మరించవచ్చా?

లేదు. కోడ్ ఎక్కడ రన్ అవుతుందనే దానితో సంబంధం లేకుండా, ఒక సైట్ ఏమి ప్రచురించింది లేదా దాని నిబంధనలు ఏమి అనుమతిస్తాయి అనేది మారదు. Draco మరియు Firecrawl రెండూ డిఫాల్ట్‌గా robots.txt ని పాటిస్తాయి. మీరు సొంతంగా కలిగి ఉన్న లేదా క్రాల్ చేయడానికి అనుమతి ఉన్న సైట్ల కోసం override ఫ్లాగ్ అందుబాటులో ఉంది. రేట్ పరిమితులు ఎక్కడైనా అమలు చేయబడతాయి, కాబట్టి తక్కువ కాన్కరెన్సీతో కూడిన మర్యాదపూర్వకమైన --delay మీ IP అడ్రస్‌ను బ్లాక్ అవ్వకుండా కాపాడుతుంది. కేవలం challenge wall ను దాటడం ద్వారా మాత్రమే పనిచేసే stack, ఎటువంటి హెచ్చరిక లేకుండా ఎప్పుడైనా ఆగిపోవచ్చు.