Self-hosted Firecrawl के बेहतरीन विकल्प और तुलना

self-hosted Firecrawl विकल्प को क्या करना चाहिए

एक self-hosted Firecrawl विकल्प का केवल एक ही काम है: एक URL लेना और पेज को साफ markdown के रूप में वापस देना जिसे एक agent पढ़ सके। hosted APIs प्रति पेज शुल्क लेती हैं, इसलिए आपका बिल इस बात के साथ बढ़ता है कि आपका agent कितना जिज्ञासु है, जबकि एक VPS जिसके लिए आप पहले से भुगतान कर रहे हैं, वही काम कर सकता है। ये प्रोजेक्ट्स एक सवाल पर विभाजित हैं: क्या एक headless browser (बिना विंडो के चलने वाला एक वास्तविक ब्राउज़र इंजन) को आपके बॉक्स पर शुरू होना चाहिए?

यह उत्तर memory footprint, प्रत्येक पेज की लागत और खाली आने वाले पेजों को निर्धारित करता है। यह गाइड Draco, Hound और self-hosted Firecrawl release की तुलना करती है, सबसे हल्के वाले को एक pinned version पर इंस्टॉल करती है, और इसे MCP (model context protocol) के माध्यम से एक agent से जोड़ती है।

चार प्रोजेक्ट्स, और प्रत्येक वास्तव में क्या है

Draco एक बाइनरी है, जिसे Rust में लिखा गया है, और यह MIT या Apache-2.0 लाइसेंस के अंतर्गत है। Release v0.20.5 को 16 July 2026 को प्रकाशित किया गया था। draco scrape <url> markdown को stdout पर प्रिंट करता है। draco serve एक daemon चलाता है जो 127.0.0.1:3002 पर उत्तर देता है, जो कि Firecrawl द्वारा उपयोग किया जाने वाला port है। यह कोई container image ship नहीं करता है और कोई browser start नहीं करता है।

Firecrawl self-hosted hosted product के पीछे का इंजन है, जो AGPL-3.0 के अंतर्गत है। इसका docker-compose.yaml सात सेवाओं को परिभाषित करता है: playwright-service, api, redis, rabbitmq, nuq-postgres, foundationdb और foundationdb-init। आपको एक छोटा distributed system चलाने की कीमत पर वास्तविक crawl queue मिलती है।

Hound master-fetch रिपॉजिटरी में रहता है और hound-mcp के रूप में PyPI पर ship होता है, जो MIT लाइसेंस प्राप्त है, और 3 August 2026 तक इसका संस्करण 13.0.1 है। इसे Python 3.11 या उससे नए संस्करण की आवश्यकता है। यह पहले एक MCP server है और बाद में एक fetcher: यह सादे HTTP का प्रयास करता है, और केवल तब Patchright browser शुरू करता है जब सादा fetch blocked वापस आता है।

Trawl यहाँ इसलिए है क्योंकि लोग दूसरों को खोजते समय इससे मिलते हैं, और यह एक अलग काम करता है। यह एक fingerprint-patched Firefox के साथ JavaScript चुनौतियों और CAPTCHAs को हल करता है, जो एक *arr मीडिया स्टैक में FlareSolverr के प्रतिस्थापन के रूप में कार्य करता है। यह एक markdown extractor नहीं है। नीचे दिया गया शिष्टाचार (etiquette) पर अनुभाग बताता है कि क्यों यह अंतर यह तय करता है कि क्या इसे आपके एजेंट स्टैक में होना चाहिए या नहीं।

ब्राउज़र पूल छोटे VPS के लिए घातक क्यों है

प्रत्येक खुला ब्राउज़र टैब एक अलग रेंडरर प्रोसेस है, जिसमें अपना DOM (डॉक्यूमेंट ऑब्जेक्ट मॉडल) और अपना 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 पर सीमित करती है, साथ ही समान स्वैप सीमाएं भी निर्धारित करती है। Hound की compose फाइल एक ऐसे कंटेनर के लिए 3 GB निर्धारित करती है जिसमें Chromium बंडल होता है। ये वे सीमाएं हैं जिन्हें प्रोजेक्ट्स ने चुना है; ये शांत सिस्टम के माप के बजाय प्रकाशित आंकड़े हैं। इसके अलावा, Redis, RabbitMQ, PostgreSQL और FoundationDB को Firecrawl के आंकड़ों के ऊपर अपनी हिस्सेदारी चाहिए होती है।

आपके पास मौजूद RAM से अधिक की सीमा निर्धारित करने का कोई लाभ नहीं है। जब बॉक्स की मेमोरी खत्म हो जाती है, तो कर्नल का out-of-memory killer एक प्रोसेस को समाप्त कर देता है, जिससे कंटेनर docker compose ps से गायब हो जाता है और एप्लिकेशन लॉग में कोई त्रुटि दर्ज नहीं होती है। किसी भी ऐसे रीस्टार्ट के बाद dmesg -T | tail को पढ़ें जिसे आप समझा नहीं सकते। पूरे Firecrawl स्टैक के लिए 8 GB का बजट रखें और 4 GB को टेस्ट-बॉक्स के लिए न्यूनतम सीमा मानें। प्रति सर्विस इन नंबरों को सेट करने की जानकारी memory limits in Docker Compose में दी गई है।

ब्राउज़र का एक और विवरण लोगों की शाम खराब कर देता है। Docker एक कंटेनर को /dev/shm पर 64 MB की शेयर्ड मेमोरी देता है, और Chromium रेंडरर बफ़र्स को वहीं रखता है, इसलिए भारी पेजों पर यह क्रैश हो जाता है। दोनों ब्राउज़र स्टैक इसे बढ़ाते हैं: Hound की compose फाइल में shm_size: "1gb" शामिल है। उस लाइन को किसी भी ऐसी इमेज में कॉपी करें जिसे आप Playwright के इर्द-गिर्द बनाते हैं।

JavaScript-heavy पेजों पर एक्सट्रैक्शन की गुणवत्ता

Static HTML, सर्वर-रेंडर किए गए ब्लॉग, डॉक्यूमेंटेशन पेज या समाचार लेखों पर, ये सभी लगभग एक समान markdown लौटाते हैं और सबसे तेज़ परिणाम देने वाला विकल्प ही बेहतर होता है। अंतर client-rendered पेजों पर दिखाई देता है, जहाँ डिलीवर किया गया HTML एक खाली शेल होता है और टेक्स्ट लोड होने के बाद JavaScript के माध्यम से आता है।

Draco टियर्स (tiers) में काम करता है। Tier 0 और tier 1 बिना किसी JavaScript के HTML को पार्स करते हैं। Tier 2 पेज के अपने JavaScript को एक in-process V8 isolate के अंदर चलाता है, जो बिना ब्राउज़र वाला JavaScript इंजन है। README के अनुसार, वहाँ पेज कोड को कोई host capability bindings नहीं मिलती हैं। यह ब्राउज़र की तुलना में बहुत कम मेमोरी का उपयोग करके कई single-page applications को कवर कर लेता है। जब Draco किसी ऐसी बाधा का सामना करता है जिसे वह पार नहीं कर सकता, तो draco scrape कोड 3, needs_browser के साथ exit हो जाता है। इसे स्क्रिप्ट्स में चेक करें, क्योंकि शून्य exit कोड वाली खाली फाइल वह विफलता है जो चुपचाप एजेंट के कॉन्टेक्स्ट को खराब कर देती है:

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

Firecrawl की playwright-service एक वास्तविक Chromium को चलाती है, इसलिए यह वही रेंडर करती है जो एक ब्राउज़र रेंडर करता है। self-hosted बिल्ड अभी भी hosted प्रोडक्ट नहीं है: डॉक्यूमेंटेशन के अनुसार self-hosted instances के पास Fire Engine का एक्सेस नहीं होता है, इसलिए क्लाउड सर्विस की anti-blocking और IP rotation सुविधाएँ उपलब्ध नहीं हैं, और /agent तथा /browser एंडपॉइंट्स समर्थित नहीं हैं। Hound जानबूझकर इनके बीच में स्थित है। यह HTTP के माध्यम से फेच करता है और प्रति अनुरोध एस्केलेट करता है, और इसका warm ब्राउज़र idle टाइमआउट के बाद बंद हो जाता है, इसलिए एक शांत बॉक्स बेसलाइन के करीब रहता है।

Draco को एक निश्चित version के साथ install करें

README में एक-लाइन वाला installer दिया गया है। इसे shell में pipe करने से पहले यह समझें कि यह क्या करता है: यह $HOME/.draco/bin/draco में install होता है, यह हमेशा latest release लेता है, और यह किसी signature या hash की जाँच नहीं करता है। सर्वर पर, version को pin करें और download को verify करें।

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 print करता है। FAILED लाइन का मतलब है कि आपके पास मौजूद bytes वे नहीं हैं जो project ने publish किए थे, इसलिए उन्हें delete करें और फिर से शुरू करें।

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

अंतिम command example page को एक second से भी कम समय में markdown के रूप में print करती है। find सजावट नहीं है: archive layout project के public contract का हिस्सा नहीं है, और official installer binary को उसी तरह ढूँढता है।

Daemon को अपने login user के बजाय उसके अपने account के अंतर्गत चलाएँ। /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

जैसे ही daemon listening mode में होता है, /health जवाब देता है। Connection refused का मतलब है कि वह listening नहीं है, इसलिए journalctl -u draco -n 50 पढ़ें। इसका सामान्य कारण यह है कि कोई अन्य process पहले से ही 3002 port का उपयोग कर रही है, क्योंकि यह Firecrawl का भी default port है, और --port दोनों में से किसी एक को बदल देता है। Unit files के बारे में अधिक जानकारी यहाँ है: systemd service units and timers।

अब उस तरीके को fetch करें जिसका उपयोग आपका agent करेगा:

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 को public internet से दूर रखें

बिना authentication वाला fetch API एक open proxy होता है। जो कोई भी उस port तक पहुँच सकता है, वह आपके server से किसी भी URL को आपके IP address के तहत request करवा सकता है। इसके बाद abuse report आपके provider के पास जाएगी, न कि उस व्यक्ति के पास। Draco के documented serve flags में कोई API key शामिल नहीं है, इसलिए सुरक्षा network स्तर पर ही होनी चाहिए। जब agent उसी box पर चल रहा हो, तो default 127.0.0.1 bind का ही उपयोग करें। जब agent कहीं और हो, तो दोनों सिरों को एक private tunnel पर रखें; स्वयं द्वारा host किया गया WireGuard VPN इसके लिए सामान्य समाधान है। उस स्थिति में 0.0.0.0 के बजाय tunnel address पर bind करें। इसके बाद किसी अन्य machine से जाँचें कि public IP पर कोई response तो नहीं मिल रहा है। ufw firewall की बुनियादी बातें और न्यूनतम विशेषाधिकार वाले user accounts इस सुरक्षा के दोनों पहलुओं को कवर करते हैं।

क्या आपके एजेंट का कोड बदलेगा? व्यवहार में API अनुकूलता

Draco, Firecrawl v1 रूट्स: /v1/scrape, /v1/map, /v1/crawl, /v1/batch/scrape और /v1/search का उत्तर देता है, और इसके README में लिखा है कि अज्ञात fields को स्वीकार किया जाता है और अनदेखा कर दिया जाता है। एक एजेंट जो पहले से ही /v1/scrape पर पोस्ट करता है, उसे केवल एक नए base URL की आवश्यकता है और कुछ नहीं। देखें कि दूसरी तरफ क्या बदला है: Firecrawl का अपना self-hosting पेज अब /v2/crawl के साथ परीक्षण करता है, और वर्तमान SDKs v2 का उपयोग करते हैं, इसलिए Draco पर पॉइंट किया गया v2 क्लाइंट ऐसे रूट के लिए अनुरोध करता है जिसे Draco पब्लिश नहीं करता है। एजेंट कोड को एडिट करने से पहले curl के साथ प्रत्येक कॉल का परीक्षण करें, और status code के बजाय JSON body को पढ़ें, क्योंकि field के नाम ही वे जगहें हैं जहाँ ये implementations एक-दूसरे से अलग हो जाते हैं।

Robots.txt, rate limits, और वह सीमा जिसका पालन करना है

Draco डिफ़ॉल्ट रूप से robots.txt को पढ़ता है, और --ignore-robots इसे बंद कर देता है। Firecrawl भी यही डिफ़ॉल्ट व्यवहार अपनाता है। दोनों को न बदलें। इसके बाद अपनी गति निर्धारित करें: --delay अनुरोधों के बीच मिलीसेकंड का अंतराल डालता है और --max-concurrency समानांतर कार्यों (parallel jobs) की सीमा तय करता है, जिसमें daemon का डिफ़ॉल्ट मान 8 है। साझा VPS लिंक पर दो से चार की संख्या अधिक उचित है और यह कुल मिलाकर शायद ही कभी धीमी होती है, क्योंकि जो साइट आपको rate limit करना शुरू कर देती है, वह concurrency से बचाए गए समय की तुलना में अधिक मिनट बर्बाद करती है। जो आप fetch करते हैं उसे cache करें, ताकि agent के दूसरी बार चलने पर स्रोत (source) पर कोई भार न पड़े। यह AI agent की लागत को नियंत्रित करने में सबसे सस्ता विकल्प भी है।

Challenge walls एक अलग विषय है, और Trawl विशेष रूप से इसी के लिए बनाया गया है: Cloudflare Turnstile, reCAPTCHA, hCaptcha और GeeTest। Challenge wall का अर्थ है कि कोई साइट स्पष्ट रूप से स्वचालित ट्रैफ़िक को अस्वीकार कर रही है। इसे दरकिनार करना आपको साइट की उपयोग की शर्तों के विरुद्ध खड़ा करता है, और कुछ स्थानों पर यह कानून के भी विरुद्ध है, इसलिए यह गाइड केवल इंफ्रास्ट्रक्चर को fetch करने तक ही सीमित है। जो तकनीकें 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 केवल तब काम करता है जब एजेंट प्रोसेस और बाइनरी एक ही मशीन पर हों, क्योंकि ट्रांसपोर्ट उस प्रोसेस का स्टैंडर्ड इनपुट होता है। किसी अन्य होस्ट पर मौजूद एजेंट के लिए, Hound इसके बजाय HTTP पर MCP सर्व करता है: hound --http --host 127.0.0.1 --port 8765, http://127.0.0.1:8765/mcp पर एक एंडपॉइंट पब्लिश करता है, जिसे आप टनल के माध्यम से एक्सेस कर सकते हैं। ट्रांसपोर्ट के विकल्प और क्या एक्सपोज़ करना है, इसकी जानकारी VPS पर MCP सर्वर चलाने में दी गई है।

सर्च के साथ पेयर फेच करना। जो एजेंट केवल फेच कर सकता है, वह आपके द्वारा URL प्रदान करने की प्रतीक्षा करता है। एक self-hosted SearXNG सर्च इंस्टेंस जोड़ें और यह उन्हें स्वयं ढूंढ सकता है, जो SearXNG पर निर्मित ब्राउज़र सर्च स्किल के समान ही है। एक बार डेमन चालू हो जाने पर, यह आपके द्वारा चलाए जाने वाले किसी भी self-hosted AI एजेंट के लिए एक साझा सर्विस बन जाता है।

FAQ

क्या AI agent के लिए पेज fetch करने हेतु मुझे headless browser की आवश्यकता है?

अधिकांश पेजों के लिए इसकी आवश्यकता नहीं है। सर्वर-रेंडर की गई documentation, ब्लॉग और समाचार लेख एक साधारण HTTP fetch और उसके बाद HTML-to-markdown step से पूर्ण रूप से प्राप्त हो जाते हैं। Draco अपने निचले tiers में इसी प्रक्रिया का उपयोग करता है, जो प्रोजेक्ट के आंकड़ों के अनुसार प्रति पेज लगभग 300 ms का समय लेती है और इसमें ब्राउज़र की आवश्यकता नहीं होती। ब्राउज़र का उपयोग तब आवश्यक होता है जब application client-side रेंडर होती है और प्राप्त HTML एक खाली शेल होता है। Draco का V8 isolate बिना किसी ब्राउज़र प्रक्रिया के इस मध्यवर्ती स्थिति को संभाल लेता है, और जब यह ऐसा करने में असमर्थ होता है, तो यह needs_browser कोड 3 के साथ exit हो जाता है।

VPS पर self-hosted Firecrawl को कितनी RAM की आवश्यकता होती है?

इसका compose file api container पर 8 GB और Playwright container पर 4 GB की सीमा निर्धारित करता है। यही stack Redis, RabbitMQ, PostgreSQL और FoundationDB को भी शुरू करता है। 8 GB RAM की योजना बनाकर चलें। 2 GB वाले सर्वर पर load बढ़ने पर kernel का out-of-memory killer कंटेनरों को हटा देता है। इसका पहला संकेत docker compose ps में कंटेनर का restart होना है, जबकि application log में कोई उपयोगी जानकारी नहीं मिलती। इसकी पुष्टि dmesg -T | tail के माध्यम से करें।

क्या Draco, Firecrawl API का सीधा विकल्प (drop-in replacement) है?

v1 endpoints के लिए यह काफी हद तक समान है। यह /v1/scrape, /v1/map, /v1/crawl, /v1/batch/scrape और /v1/search को serve करता है और उन request fields को अनदेखा कर देता है जिन्हें वह नहीं पहचानता। इसलिए, Firecrawl v1 के लिए लिखे गए client को आमतौर पर केवल एक नए base URL की आवश्यकता होती है। यह hosted product नहीं है: इसके पीछे कोई managed proxy pool नहीं है, और Firecrawl के नए v2 routes इसके दायरे में नहीं हैं। अपने agent द्वारा की जाने वाली प्रत्येक call को पहले curl के साथ verify करें।

क्या scraper को self-host करने का अर्थ यह है कि मैं robots.txt को अनदेखा कर सकता हूँ?

नहीं। कोड कहाँ चलता है, इससे इस बात पर कोई फर्क नहीं पड़ता कि किसी साइट ने क्या प्रकाशित किया है या उसकी शर्तें क्या अनुमति देती हैं। Draco और Firecrawl दोनों डिफ़ॉल्ट रूप से robots.txt का सम्मान करते हैं। override flag उन साइटों के लिए मौजूद है जिनके आप स्वामी हैं या जिन्हें crawl करने की आपके पास लिखित अनुमति है। Rate limits को अंततः दूरस्थ सर्वर द्वारा लागू किया जाता है, इसलिए कम concurrency के साथ एक विनम्र --delay आपके IP address को सक्रिय रखता है। जो stack केवल challenge wall को पार करके ही काम करता है, वह बिना किसी चेतावनी के कभी भी बंद हो सकता है।