ज़्यादातर लोग Firecrawl को स्क्रैपिंग लाइब्रेरीज़ की कतार में डाल देते हैं — यानी pip install करो, एक स्क्रिप्ट लिखो, और काम खत्म। यह समझ गलत है, और फर्क़ समझना एक भी कमांड टाइप करने से पहले ज़रूरी है। Firecrawl self-hosted कोई ऐसी लाइब्रेरी नहीं है जिसे आप import करते हैं; यह एक सेवा है जिसे आप चलाते हैं, और इसे खड़ा करने का मतलब है छह Docker containers को साथ में चलाना, जो आपस में बात करते हैं।
मैंने self-hosted stack को Mac (arm64, Docker via colima) पर बिना cloud key के चलाया, इसके /v1/scrape endpoint को scraping-friendly demo sites की कुछ साइटों पर point किया, और देखा कि क्या निकलकर आता है। संक्षेप में: इसका मुख्य वादा सही साबित हुआ — एक पेज गया, साफ़-सुथरा LLM-ready Markdown वापस आया — लेकिन जितना सेटअप इस tool के साथ करना पड़ा, उतना इस research base में किसी और tool के साथ नहीं पड़ा। यह अभी provisional नज़र है, final rating नहीं, और मैं साफ़ बताऊँगा कि मैंने क्या test किया और क्या नहीं।
Firecrawl एक Service है, Library नहीं
सबसे पहले mental model ठीक करना होगा। ज़्यादातर developers जिन scraping tools को चुनते हैं, वे libraries होते हैं: आप dependency जोड़ते हैं, function call करते हैं, और HTML या parsed data अपने process के भीतर वापस मिल जाता है। Firecrawl self-hosted अलग तरह की चीज़ है। यह एक running platform है, इसका अपना API है, और आप इससे HTTP के ज़रिए बात करते हैं।
Official positioning है “the API to search, scrape, and interact with the web at scale,” और product का shape भी वही है — pages अंदर, clean Markdown या structured data बाहर। जब आप इसे self-host करते हैं, तो आप Firecrawl को link नहीं कर रहे होते। आप docker compose stack खड़ा कर रहे होते हैं और एक endpoint hit कर रहे होते हैं, ठीक वैसे ही जैसे किसी internal microservice को करते हैं।
जो stack मैंने चलाया, उसमें छह services थीं:
- api — HTTP surface जिसे आप सीधे call करते हैं
- playwright-service — JavaScript rendering के लिए headless browser
- redis — queue और cache
- rabbitmq — message broker
- nuq-postgres — job state के लिए Postgres flavor
- foundationdb — distributed key-value storage
यह असली backend है, कोई helper script नहीं। Redis, RabbitMQ, Postgres, और FoundationDB—सब अपने आप में industrial-grade infrastructure हैं। इसका फायदा यह है कि Firecrawl scraping के messy हिस्से—queueing, rendering, retries—को एक API call के पीछे संभाल लेता है। कीमत यह है कि अब इन छह containers का संचालन आपकी जिम्मेदारी है। इस trade-off को ध्यान में रखें; यही इस पूरे review की मुख्य धुरी है।
Reference के लिए, मैंने firecrawl-py 4.32.0 और firecrawl-js 4.30.0 SDKs के साथ test किया, और 2026-07-09 को official prebuilt ghcr.io/firecrawl/firecrawl:latest image pull किया। उस तारीख तक repo के करीब 148k stars थे (इसे metadata समझें, quality score नहीं), और यह AGPL-3.0 license के तहत है — एक ऐसा पहलू जिस पर मैं बाद में लौटूँगा, क्योंकि यह commercial use का calculus बदल देता है।
Core Test: एक Page से Clean Markdown
Firecrawl का पूरा मकसद ही यही है कि web page को ऐसा Markdown बनाया जाए जिसे LLM सच में पढ़ सके। इसलिए मैंने सबसे पहले यही देखा।
मैंने /v1/scrape को books.toscrape.com पर point किया, जो scraping practice के लिए बनाया गया static catalog है। नतीजा: 9,222 characters का साफ़, LLM-ready Markdown, और page title All products | Books to Scrape सही तरीके से parse हुआ। यह raw HTML नहीं था जो string में dump कर दिया गया हो — यह structured Markdown था, headings, links, और image references के साथ intact। ऐसा output जिसे आप सीधे किसी retrieval pipeline में डाल सकते हैं या बिना दूसरी cleaning pass के model को दे सकते हैं।
यही Firecrawl की headline strength है, और self-hosted संस्करण ने इसे बिना किसी drama के deliver किया। अगर आपका काम है “इस page की readable substance मुझे Markdown में दो,” तो static page ने ठीक वैसा ही जवाब दिया जैसा वादा किया गया था। यह सचमुच उपयोगी primitive है, और इसी वजह से यह tool इतना popular है।
Scope को लेकर एक बात साफ़: मैंने केवल single-page /v1/scrape path test किया। मैंने /v1/crawl test नहीं किया, जो पूरे site को walk करने वाला multi-page crawler है। यह अलग capability है, इसके अपने failure modes हैं, और जिसे मैंने run ही नहीं किया उसके काम करने का दावा मैं नहीं करूँगा।
JavaScript Pages: Bundled Browser अपनी कीमत वसूलता है
Static page तो आसान मामला है। किसी भी scraper के लिए असली सवाल यह है कि जब content केवल JavaScript चलने के बाद दिखाई दे, तब क्या होता है — और modern web पर यह अक्सर होता है।
यहीं playwright-service container overhead नहीं, बल्कि असली कारण बन जाता है। मैंने scraper को quotes.toscrape.com/js/ पर point किया, जो demo site का वह version है जहाँ quotes client-side render होते हैं। अगर Firecrawl सिर्फ raw HTML fetch करता, तो quotes मौजूद नहीं होते — browser के script चलाए बिना वे पैदा ही नहीं होते।
Scrape से 1,574 characters का Markdown मिला, और उसमें Einstein quote भी था। वह quote JavaScript के बाद का content है: उसका मौजूद होना इस बात का प्रमाण है कि playwright-service ने text extract करने से पहले page को real browser engine में render किया, सिर्फ़ खाली pre-render shell नहीं उठा लिया।
तो छह containers में से एक headless browser है, और वह वही काम करता है जिसके लिए उसे रखा गया है। यही heavier architecture की concrete justification है: आप सिर्फ़ containers के लिए pay नहीं कर रहे, बल्कि इस capability के लिए pay कर रहे हैं कि बिना अपनी browser automation बनाए, JS-heavy pages render हो सकें। कई असली-world targets के लिए यही usable output और खाली divs के बीच का फर्क है।
जब Target खराब हो: Structured Error, Crash नहीं
Scrapers अक्सर उन चीज़ों पर लगाए जाते हैं जो काम ही नहीं करतीं — dead hosts, गलत URLs, बंद हो जाने वाले servers। कोई tool fail कैसे करता है, यह उतना ही बताता है जितना कि वह सफल कैसे होता है।
मैंने जानबूझकर API को एक invalid host दिया। उसने structured HTTP 500 लौटाया और चलता रहा — client को कोई stack trace नहीं उगला, कोई container नहीं गिरा, कोई process hang नहीं हुआ। Error एक clean response के रूप में वापस आया, जिस पर caller logic के हिसाब से branch कर सकता है।
यही boring, सही behavior आप उस चीज़ से चाहते हैं जिसे आप pipeline में डालेंगे। जो scraper bad target पर panic कर जाए, उसे आप automation में भरोसे से इस्तेमाल नहीं कर सकते। इसने एक error वापस दिया जिसे आप पकड़कर आगे बढ़ सकते हैं। मैंने सिर्फ़ एक error case test किया, इसलिए इसे “जो एक failure मैंने फेंका, उसे सही तरह संभाला” के रूप में पढ़ें, exhaustive resilience audit के रूप में नहीं — लेकिन जो एक data point मिला, वह सही नतीजा था।
Setup की हकीकत: इस Base का सबसे भारी काम
अब वह हिस्सा, जिसकी launch tweet में कोई screenshot नहीं डालता। Firecrawl self-hosted, बिना exaggeration के, इस research base में test किए गए किसी भी tool का सबसे involved setup था — और मैंने ऐसे बहुत से tools खड़े किए हैं।
छह containers baseline cost हैं। लेकिन ऊपर जाते समय मुझे दो और दिक्कतें भी आईं, और मैं साफ़ कहना चाहता हूँ कि गलती किसकी थी — जैसा कि निकला, Firecrawl की नहीं।
पहली दिक्कत: from-source build. source से images build करना मेरे colima VM के अंदर containerd snapshotter error के कारण fail हो गया। यह build और colima की storage layer के बीच एक जाना-पहचाना flaky interaction है — मेरे environment की infrastructure गड़बड़ी, Firecrawl का bug नहीं। compose file एक वैकल्पिक तरीका बताती है: locally build करने के बजाय official prebuilt ghcr.io/firecrawl/* images use करें। मैंने वही किया, और पूरा stack साफ़-सुथरे ढंग से ऊपर आ गया। अगर आप colima के बजाय standard Docker daemon चला रहे हों, तो शायद यह कभी दिखे ही नहीं; मैं इसे environment caveat के रूप में flag कर रहा हूँ, और clean daemon पर contributor build को validate करना मेरी gap list में है।
दूसरी दिक्कत: SSRF guard. मेरी शुरुआती scrapes Firecrawl के private-IP / SSRF protection द्वारा block कर दी गईं। क्यों? colima networking public hostnames को 198.18.x.x addresses पर map करती है, जो reserved range में आते हैं और Firecrawl उन्हें सही तौर पर private मानता है — यानी security layer ने अपना काम किया और ऐसे target को fetch करने से मना कर दिया जो internal जैसा लग रहा था। इसे सिर्फ local testing के लिए bypass करने हेतु मैंने ALLOW_LOCAL_WEBHOOKS=true set किया।
यह flag अगर production में copy-paste हो गया, तो incident करा सकता है, इसलिए इसे ठीक-ठीक समझें: SSRF guard एक feature है, obstacle नहीं। यही scraping service को trick होकर आपके internal network पर hit करने से रोकता है। मैंने इसे इसलिए disable किया क्योंकि colima के DNS की एक अजीबता ने मेरे legitimate public targets को VM के भीतर private जैसा दिखा दिया। असली deployment में SSRF protection बंद मत कीजिए। इस review से अगर एक operational note ले जाएँ, तो वही लें।
सीधी बात यह है कि दोनों problems मेरे laptop पर colima के through Docker चलाने के artifacts थे — software की खामी नहीं। दूसरी तरफ, setup का भारीपन real है और design से Firecrawl का हिस्सा है। यह वह tool नहीं है जिसे आप त्वरित local script के लिए उठाएँ; यह वह tool है जिसे आप तब खड़ा करते हैं जब आपको rendering-capable scraping service चाहिए और आप उसके लिए infrastructure चलाने को तैयार हैं।
मैंने क्या नहीं टेस्ट किया, और यह क्या नहीं देता
यहाँ वह चीज़ें हैं जो मैंने cover नहीं कीं, और जो tool देता ही नहीं।
Self-hosted में Fire-engine नहीं है। Firecrawl के cloud product में Fire-engine आता है, जो bots defenses को पार करने के लिए उसका proprietary anti-block layer है। Project के अपने SELF_HOST.md के अनुसार, self-hosted instances को यह नहीं मिलता। इसलिए अगर आप सोच रहे हैं कि self-hosted Firecrawl out of the box aggressive anti-bot systems को punch through कर देगा, तो picture बदलनी होगी — वह capability cloud tier में है, और मैंने जो चलाया उसमें शामिल नहीं थी।
Cloud API यहाँ test नहीं हुई। मेरे पास cloud key नहीं था, इसलिए ऊपर की सारी बातें केवल self-hosted stack पर आधारित हैं। Managed cloud service — Fire-engine, hosted scaling, और AI features के साथ — एक अलग product है, और मैं बाहर से देखकर उसकी performance का दावा नहीं करूँगा। Cloud से जुड़ा कोई भी दावा इस review के scope से बाहर समझें।
AI features के लिए key चाहिए। json structured-output format और /extract endpoint LLM पर निर्भर हैं, यानी OpenAI key लानी होगी या Ollama set up करना होगा। मैंने ये paths test नहीं किए, इसलिए /extract और structured json output भी untested column में ही हैं।
Proxies एक caveat हैं, headline नहीं। Firecrawl proxy configuration support करता है, लेकिन मैं इसे जान-बूझकर footnote की तरह रख रहा हूँ — यह एक knob है जिसे आप turn कर सकते हैं, tool चुनने का कारण नहीं, और self-hosted में cloud वाला anti-block layer वैसे भी नहीं आता।
AGPL-3.0 एक असली compliance decision है। इस पर अलग से बात करनी चाहिए।
License: Ship करने से पहले AGPL-3.0 पढ़िए
Firecrawl AGPL-3.0 के तहत licensed है। यह README के नीचे की कोई हल्की-फुल्की लाइन नहीं है — यह strong copyleft है, network-use clause के साथ, और यह सीधे प्रभावित कर सकता है कि आप self-hosted instance पर commercial product बना भी सकते हैं या नहीं।
संक्षेप में: standard GPL obligations distribution पर trigger होती हैं। AGPL इससे आगे जाती है — network-use provision का मतलब है कि software की functionality को network के ज़रिए users को देना भी उस तरह के use में आ सकता है जिस पर source availability obligations लागू हों। अगर आप self-hosted Firecrawl को ऐसी service में embed कर रहे हैं जिसे आपके customers internet के ज़रिए पहुँचते हैं, तो वह clause पूरी तरह लागू होता है, और “हमने कभी binary ship ही नहीं की” वह escape hatch नहीं है जैसा लोग अक्सर मान लेते हैं।
मैं आपका वकील नहीं हूँ, और license interpretation इस पर निर्भर करती है कि आप इसे ठीक कैसे deploy करते हैं। लेकिन किसी भी commercial recommendation के लिए AGPL-3.0 पहली-श्रेणी की consideration है, कोई fine print नहीं। इसे अपनाने से पहले अपनी company में licensing संभालने वाले व्यक्ति को शामिल कीजिए। यह बात Firecrawl पर चोट नहीं है — बहुत सारे बेहतरीन tools AGPL हैं — बस यह एक तथ्य है जो शुरुआत में मेज पर होना चाहिए।
Thunderbit का Developer Stack कहाँ फिट बैठता है
Web Data Extraction के लिए Thunderbit आज़माएँ
अगर आपका असली लक्ष्य “page → LLM-ready Markdown” या “page → structured data” है, और छह-container वाला operational tax तथा AGPL वाला सवाल ऐसा नहीं है जिसे आप खुद संभालना चाहें, तो यही gap Thunderbit का developer stack भरने के लिए बनाया गया है। वही AI engine जो हमारे 100,000+ extension users के पीछे है, technical काम के लिए तीन तरीकों से उपलब्ध है — जबकि infrastructure हमारी तरफ़ संभाली जाती है।
- Open API (REST).
POST /distillकिसी page को साफ़, LLM-ready Markdown में बदलता है;POST /extractआपके द्वारा परिभाषित JSON Schema के खिलाफ structured data लौटाता है। JS rendering, anti-bot handling, और dynamic content server-side संभाले जाते हैं — आपको अपना browser container नहीं चलाना पड़ता।renderModeflag (none/basic/full) तय करता है कि rendering कितनी गहराई से होगी, और batch endpoints distill के लिए 100 URLs तक संभालते हैं। - MCP server. एक official Model Context Protocol server, ताकि Claude या Cursor के अंदर चल रहा AI agent task के बीच में scrape कर सके: extraction plan बनाने के लिए
thunderbit_suggest_fields(free), Markdown के लिएthunderbit_distill, structured data के लिएthunderbit_extract। Agent यह तय करता है कि data कब pull करना है, और उसे अपना environment छोड़ना नहीं पड़ता। - CLI.
npx -y @thunderbit/thunderbit-cliterminal, scripts, CI, या cron से scrapes चलाता है — browser नहीं, babysit करने को stack नहीं। इसे सीधे दूसरे tools में pipe कर सकते हैं:thunderbit distill "$URL" -f markdown | claude -p "summarise".
Self-hosted Firecrawl के साथ contrast साफ़ है। Firecrawl self-hosted आपको full control और full operational ownership देता है: छह containers, setup का बोझ, AGPL terms, और anti-block के लिए Fire-engine नहीं। Thunderbit का API/MCP/CLI उस control के बदले hosted engine देता है जो schema-matched structured JSON लौटाता है — सिर्फ़ raw Markdown नहीं — और containers, anti-bot layer, तथा copyleft obligations आपके सिर से हट जाती हैं। अलग infrastructure appetite के लिए अलग tools।
एक नज़र में trade-off:
| विचार | Firecrawl self-hosted | Thunderbit dev stack (API · MCP · CLI) |
|---|---|---|
| Deployment shape | Service जिसे आप चलाते हैं (6 containers) | Hosted API जिसे आप call करते हैं |
| शुरू करने के लिए | 6-service stack के लिए docker compose up | API key, फिर request |
| JS rendering | Bundled playwright-service (आप चलाते हैं) | Server-side, renderMode flag |
| Structured output | LLM key चाहिए (/extract, json) | JSON Schema के साथ POST /extract |
| Anti-bot layer | Self-hosted में नहीं (Fire-engine cloud-only है) | Server-side संभाला जाता है |
| License | AGPL-3.0 (network-use copyleft) | Commercial API, आपके code पर copyleft नहीं |
| सबसे अच्छा तब जब | आपको full control चाहिए और infra चलानी है | आपको ops के बिना Markdown/structured data चाहिए |
इनमें से कोई भी सार्वभौमिक रूप से “बेहतर” नहीं है। अगर platform चलाना ही आपके लिए मकसद है — full data control, external dependency नहीं, और आपकी स्थिति में AGPL fit बैठता है — तो self-hosted Firecrawl एक सक्षम, actively maintained विकल्प है। अगर आप बस API call करना चाहते हैं और छह-container वाले जीवन से बचना चाहते हैं, तो Thunderbit stack की यही pitch है।
आखिर Firecrawl self-host किसे करना चाहिए
हype हटाइए, तस्वीर ज़रूरत के हिसाब से साफ़ हो जाती है।
Self-host Firecrawl अगर आप अपने scraping infrastructure पर full control चाहते हैं, production में Redis / RabbitMQ / Postgres / FoundationDB चलाने में सहज हैं, rendering की ज़रूरतें playwright-service container को उचित ठहराती हैं, और AGPL-3.0 आपकी deployment strategy के साथ काम करती है। Core capability असली है: मुझे static और JS-rendered दोनों page से साफ़, structured, LLM-ready Markdown मिला, और पूरा stack prebuilt images पर चला।
कहीं और देखिए अगर आपको जल्दी local script चाहिए (सीधे शब्दों में, यह इस base का सबसे भारी setup है), आपको cloud-grade anti-block चाहिए बिना उसे खुद चलाए (self-host में Fire-engine नहीं है), या AGPL network-use clause आपकी commercial planning से टकराता है। “मुझे बस किसी URL से Markdown या structured data चाहिए, ops नहीं” वाले case में Thunderbit का /distill और /extract जैसा hosted API वही काम containers के बिना कर देता है।
मेरा provisional निष्कर्ष: core मजबूत है, operational commitment भारी है, और commercial build से पहले license clear करना अनिवार्य है। जो teams पूरे pipeline का ownership चाहती हैं, उनके लिए यह अपनी जगह कमाता है — और बाकी सब से काफी कुछ माँगता है। मैं इसे तब फिर देखूँगा जब मैं /v1/crawl चला लूँगा, /extract को LLM key के साथ test कर लूँगा, और from-source build को non-colima daemon पर validate कर लूँगा; final verdict से पहले यही open questions हैं।
Web Data Extraction के लिए Thunderbit आज़माएँ Get Started Free
FAQs
क्या self-hosted Firecrawl cloud version जैसा ही है?
नहीं। Self-hosted आपको core scrape-to-Markdown engine और bundled playwright-service के ज़रिए JavaScript rendering देता है, लेकिन इसमें Fire-engine नहीं होता, जो cloud product का proprietary anti-block layer है। /extract endpoint और json output जैसी AI features के लिए भी आपकी अपनी LLM key (OpenAI या Ollama) चाहिए। इस review में मैंने केवल self-hosted stack test किया; cloud API scope से बाहर थी।
Self-hosted Firecrawl को वास्तव में कितने containers चाहिए? छह: api, playwright-service, redis, rabbitmq, nuq-postgres, और foundationdb। यह एक full service stack है, कोई single binary नहीं — और यही वजह है कि यह इस research base में सबसे भारी setup था। सिर्फ़ script नहीं, बल्कि message-broker, cache, और database infrastructure चलाने के operational overhead के लिए भी तैयार रहें।
क्या Firecrawl self-hosted रहते हुए JavaScript-heavy pages संभाल सकता है? हाँ, मेरे test में। Bundled playwright-service pages को extraction से पहले real browser engine में render करता है। मैंने इसे quotes.toscrape.com/js/ पर confirm किया, जहाँ Einstein quote — यानी ऐसा content जो JavaScript चलने के बाद ही मौजूद होता है — returned Markdown में दिखाई दिया। Rendering capability ही वजह है कि छह containers में से एक headless browser है।
क्या AGPL-3.0 license commercial use को प्रभावित करती है? हाँ, कर सकती है, और इसे पहली ज़रूरत की बात मानना चाहिए। AGPL-3.0 strong copyleft है network-use clause के साथ, जिसका मतलब है कि software की functionality users को network के ज़रिए देना source-availability obligations ला सकता है — भले ही आपने कभी binary distribute न की हो। अगर आप self-hosted instance पर commercial product बनाना चाहते हैं, तो commit करने से पहले अपनी कंपनी में licensing संभालने वाले व्यक्ति से बात करें। यह review license को flag करता है; यह legal advice नहीं है।
Firecrawl और Thunderbit के developer tools में क्या फर्क है?
Firecrawl self-hosted एक service है जिसे आप चलाते हैं — छह containers जिन्हें आप खुद run करते हैं, AGPL-3.0 terms के साथ और built-in anti-block layer के बिना। Thunderbit का developer stack (Open API, MCP server, CLI) एक hosted engine है जिसे आप call करते हैं: Markdown के लिए POST /distill, JSON-Schema-structured data के लिए POST /extract, साथ में JS rendering और anti-bot handling server-side, और आपके अपने code पर copyleft obligation नहीं। Firecrawl उन teams के लिए है जिन्हें full infrastructure control चाहिए; Thunderbit उन लोगों के लिए है जिन्हें operational load के बिना output चाहिए।
