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

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

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

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

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

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

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

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

Trawl यहाँ इसलिए है क्योंकि लोग दूसरों को खोजते समय इसका सामना करते हैं, और यह एक अलग काम करता है। यह एक फिंगरप्रिंट-पैच्ड Firefox के साथ JavaScript चुनौतियों और CAPTCHAs को हल करता है, जो *arr मीडिया स्टैक में FlareSolverr के विकल्प के रूप में कार्य करता है। यह मार्कडाउन एक्सट्रैक्टर नहीं है। नीचे शिष्टाचार (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 को टेस्ट-बॉक्स के लिए न्यूनतम सीमा मानें। प्रति सर्विस इन नंबरों को सेट करने की प्रक्रिया Docker Compose में मेमोरी सीमाएं में कवर की गई है।

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

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

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

Draco टियर्स (tiers) में काम करता है। Tier 0 और tier 1 बिना किसी JavaScript के HTML को पार्स करते हैं। Tier 2 पेज के अपने JavaScript को इन-प्रोसेस 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

/health daemon के listening होते ही जवाब देता है। Connection refused का अर्थ है कि यह listening नहीं है, इसलिए journalctl -u draco -n 50 पढ़ें। इसका सामान्य कारण यह है कि कोई अन्य process पहले से ही 3002 port को hold किए हुए है, क्योंकि यह 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 के प्रलेखित 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 की बुनियादी जानकारी और least privilege user accounts इस सुरक्षा के दोनों पहलुओं को कवर करते हैं।

क्या आपके एजेंट कोड में बदलाव होगा? व्यवहार में 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 के साथ परीक्षण करता है, और वर्तमान SDKs v2 का उपयोग करते हैं, इसलिए Draco की ओर निर्देशित एक v2 क्लाइंट ऐसे रूट के लिए अनुरोध करता है जिसे Draco पब्लिश नहीं करता है। एजेंट कोड को एडिट करने से पहले curl के साथ प्रत्येक कॉल का परीक्षण करें, और status code के बजाय JSON बॉडी को पढ़ें, क्योंकि फील्ड के नाम ही वह जगह हैं जहाँ ये इम्प्लीमेंटेशन एक-दूसरे से अलग हो जाते हैं।

Robots.txt, rate limits, और मर्यादा का पालन

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

Challenge walls एक अलग विषय हैं, और Trawl विशेष रूप से इसी के लिए बनाया गया है: Cloudflare Turnstile, reCAPTCHA, hCaptcha और GeeTest। एक challenge wall का अर्थ है कि साइट स्पष्ट रूप से स्वचालित ट्रैफ़िक को अस्वीकार कर रही है। इसे बायपास करना आपको साइट की उपयोग की शर्तों के विरुद्ध खड़ा करता है, और कुछ स्थानों पर यह कानून के भी विरुद्ध है, इसलिए यह गाइड केवल fetching इंफ्रास्ट्रक्चर तक ही सीमित है। जो तकनीकें wall को पार करने के काम आती हैं, साइट के मालिक उन्हीं पर नज़र रखते हैं और उन्हें ब्लॉक करते हैं, जिससे उन पर आधारित कोई भी पाइपलाइन नाजुक होने के साथ-साथ अभद्र भी हो जाती है। जब कोई स्रोत इतना महत्वपूर्ण हो, तो उसके RSS feed, public API, या bulk export की तलाश करें। प्रत्येक को चलाना सस्ता है और इनमें से कोई भी उस सप्ताह नहीं टूटता जब wall में बदलाव किया जाता है।

इसे MCP के माध्यम से एक agent से जोड़ें

MCP (model context protocol) वह interface है जिसका उपयोग कोई agent किसी tool को call करने के लिए करता है। कौन-से tools model तक पहुँचते हैं और आपको पहले पूछे बिना किसी tool को call करने की अनुमति है या नहीं, यह निर्णय एक स्तर ऊपर उस harness द्वारा लिया जाता है जिसमें model चलता है। इसलिए daemon को listening स्थिति में लाना wiring का केवल आधा भाग है। Draco में उसी binary के भीतर stdio के माध्यम से MCP server शामिल है:

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

इसके बाद ये tools agent को draco_scrape, draco_search और draco_interact_* set के रूप में दिखाई देते हैं। Stdio केवल तब काम करता है जब agent process और binary एक ही machine पर हों, क्योंकि transport उस process का standard input होता है। किसी अन्य host पर स्थित agent के लिए, Hound MCP को HTTP पर serve करता है: hound --http --host 127.0.0.1 --port 8765, http://127.0.0.1:8765/mcp पर एक endpoint publish करता है, जिसे आप tunnel के माध्यम से access कर सकते हैं। Transport के विकल्प और क्या expose करना है, इसकी जानकारी VPS पर MCP servers चलाने में दी गई है।

Search के साथ pairs प्राप्त करना। जो agent केवल fetch कर सकता है, वह आपके द्वारा URL प्रदान करने की प्रतीक्षा करता है। एक self-hosted SearXNG search instance जोड़ें और यह उन्हें स्वयं खोज सकता है, जो SearXNG पर आधारित browser search skill के समान ही है। एक बार daemon चालू हो जाने पर, यह आपके द्वारा चलाए जाने वाले किसी भी self-hosted AI agents के लिए एक साझा service बन जाता है। यदि agent वाला हिस्सा वह है जिसके बारे में आप सबसे कम सुनिश्चित हैं, तो पहले हाथ से एक छोटा agent loop लिखना यह स्पष्ट कर देता है कि fetch tool कहाँ जुड़ता है और model प्राप्त होने वाले markdown के साथ क्या करता है।

FAQ

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

अधिकांश pages के लिए इसकी आवश्यकता नहीं है। Server-rendered documentation, blogs और news articles एक साधारण HTTP fetch और उसके बाद HTML-to-markdown step से पूरी तरह प्राप्त हो जाते हैं। Draco अपने निचले tiers में यही प्रक्रिया अपनाता है, जो प्रोजेक्ट के आंकड़ों के अनुसार प्रति page लगभग 300 ms का समय लेती है और इसमें browser की आवश्यकता नहीं होती। Browser का उपयोग उन client-rendered applications के लिए किया जाता है जहाँ प्राप्त HTML केवल एक खाली shell होता है। Draco का V8 isolate बिना किसी browser process के इस कार्य का अधिकांश हिस्सा संभाल लेता है, और जब यह ऐसा करने में असमर्थ होता है, तो यह code 3, needs_browser के साथ exit हो जाता है।

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

इसका compose file api container पर 8 GB और Playwright container पर 4 GB की सीमा निर्धारित करता है। यही stack Redis, RabbitMQ, PostgreSQL और FoundationDB को भी start करता है। 8 GB RAM की योजना बनाकर चलें। 2 GB वाले box पर load बढ़ने पर kernel का out-of-memory killer containers को हटा देता है। इसका पहला संकेत docker compose ps में restart हुआ container है, जिसके 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 इस surface का हिस्सा नहीं हैं। अपने agent द्वारा की जाने वाली प्रत्येक call को पहले curl के साथ verify करें।

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

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