VPS کے لیے بہترین self-hosted Firecrawl متبادل

خود میزبان Firecrawl متبادل کو کیا کرنا چاہیے

خود میزبان Firecrawl متبادل کا بنیادی کام ایک URL لینا اور صفحہ صاف markdown کی صورت میں واپس کرنا ہے، تاکہ agent اسے پڑھ سکے۔ Hosted APIs فی صفحہ فیس لیتیں ہیں، اس لیے آپ کے agent کی جستجو بڑھنے کے ساتھ لاگت بھی بڑھتی ہے۔ جبکہ آپ کے زیرِ استعمال VPS یہی کام انجام دے سکتا ہے۔ ان projects کے درمیان بنیادی فرق ایک سوال ہے: کیا headless browser، یعنی ایسا حقیقی browser engine جو کسی window کے بغیر چلتا ہے، آپ کے box پر start ہونا ضروری ہے؟

یہ فیصلہ memory footprint، ہر صفحے کی لاگت، اور واپس ملنے والے صفحوں کے خالی ہونے کا تعین کرتا ہے۔ اس guide میں Draco، Hound اور self-hosted Firecrawl release کا موازنہ کیا گیا ہے، pinned version پر سب سے ہلکے option کو install کیا گیا ہے، اور اسے MCP (model context protocol) کے ذریعے agent سے جوڑا گیا ہے۔

چاروں projects اور ہر project کی اصل نوعیت

Draco ایک binary ہے، جو Rust میں لکھی گئی ہے اور MIT یا Apache-2.0 license کے تحت جاری کی گئی ہے۔ Release v0.20.5، 16 July 2026 کو جاری ہوئی۔ draco scrape <url> markdown کو stdout پر print کرتا ہے۔ draco serve ایک daemon چلاتا ہے جو 127.0.0.1:3002 پر درخواستیں وصول کرتا ہے؛ یہی وہ port ہے جسے Firecrawl استعمال کرتا ہے۔ یہ کوئی container image فراہم نہیں کرتا اور browser شروع نہیں کرتا۔

Firecrawl self-hosted hosted product کے پیچھے موجود engine ہے اور AGPL-3.0 کے تحت جاری کیا گیا ہے۔ اس کا docker-compose.yaml سات services کی تعریف کرتا ہے: playwright-service، api، redis، rabbitmq، nuq-postgres، foundationdb اور foundationdb-init۔ اس سے حقیقی crawl queue ملتی ہے، لیکن ایک چھوٹا distributed system چلانا پڑتا ہے۔

Hound، master-fetch repository میں موجود ہے اور PyPI پر hound-mcp کے نام سے جاری ہوتا ہے۔ یہ MIT licensed ہے اور 3 August 2026 تک version 13.0.1 ہے۔ اسے Python 3.11 یا اس کے بعد کا version درکار ہے۔ یہ پہلے MCP server اور بعد میں fetcher ہے: یہ پہلے plain HTTP آزماتا ہے، اور plain fetch کے blocked واپس آنے پر ہی Patchright browser شروع کرتا ہے۔

Trawl یہاں اس لیے شامل ہے کہ دوسرے projects تلاش کرتے وقت لوگ اس تک بھی پہنچتے ہیں، لیکن یہ مختلف کام کرتا ہے۔ یہ fingerprint-patched Firefox کے ذریعے JavaScript challenges اور CAPTCHAs حل کرتا ہے، اور *arr media stack میں FlareSolverr کے متبادل کے طور پر استعمال ہوتا ہے۔ یہ markdown extractor نہیں ہے۔ ذیل کا etiquette section واضح کرتا ہے کہ یہ فرق اس بات کا فیصلہ کیوں کرتا ہے کہ اسے آپ کے agent stack میں شامل ہونا چاہیے یا نہیں۔

براؤزر پول کی وجہ سے چھوٹے VPS سرور کیوں ناکام ہو جاتے ہیں

ہر کھلا ہوا براؤزر ٹیب ایک الگ renderer process ہوتا ہے، جس میں اپنا DOM (document object model) اور اپنا JavaScript heap ہوتا ہے۔ اس لیے memory ایک ہی وقت میں کھلے صفحات کی تعداد کے ساتھ بڑھتی ہے، نہ کہ روزانہ fetch کیے گئے صفحات کی تعداد کے ساتھ۔ ان میں سے دو projects یہ لاگت اپنی compose files میں شامل کرتے ہیں۔

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

Firecrawl کی compose file اپنے api container کی حد 8 GB اور اپنے Playwright container کی حد 4 GB مقرر کرتی ہے، اور swap limits بھی اسی کے مطابق ہیں۔ Hound کی compose file ایک ایسے container کے لیے 3 GB مقرر کرتی ہے جس میں Chromium شامل ہے۔ یہ وہ maximum limits ہیں جو projects نے منتخب کیں۔ یہ شائع شدہ اعداد ہیں، کسی idle system کی پیمائش نہیں۔ اس کے علاوہ Redis، RabbitMQ، PostgreSQL اور FoundationDB کو Firecrawl کے اعداد کے اوپر اپنی memory بھی درکار ہوتی ہے۔

آپ کے پاس موجود RAM سے زیادہ مقرر کی گئی limit کوئی فائدہ نہیں دیتی۔ جب server کی memory ختم ہو جاتی ہے تو kernel کا out-of-memory killer کسی process کو ختم کر دیتا ہے۔ اس لیے container docker compose ps سے بغیر کسی error کے غائب ہو سکتا ہے جو application log میں لکھا گیا ہو۔ ہر ایسی restart کے بعد جس کی وجہ آپ بیان نہ کر سکیں، dmesg -T | tail پڑھیں۔ مکمل Firecrawl stack کے لیے 8 GB مختص کریں اور 4 GB کو test server کی کم از کم حد سمجھیں۔ ہر service کے لیے یہ اعداد مقرر کرنے کا طریقہ Docker Compose میں memory limits میں دیا گیا ہے۔

براؤزر سے متعلق ایک اور تفصیل بھی کئی گھنٹے ضائع کر سکتی ہے۔ Docker /dev/shm پر container کو صرف 64 MB shared memory دیتا ہے، اور Chromium renderer buffers وہاں رکھتا ہے، اس لیے بھاری صفحات پر یہ crash ہو جاتا ہے۔ دونوں browser stacks اس حد کو بڑھاتے ہیں۔ Hound کی compose file میں shm_size: "1gb" شامل ہے۔ Playwright کے گرد بنائی گئی کسی بھی image میں یہ line copy کریں۔

JavaScript پر زیادہ انحصار کرنے والے صفحات سے مواد اخذ کرنے کا معیار

static HTML، server-rendered blog، documentation page اور news article پر یہ تمام ٹولز تقریباً یکساں markdown واپس کرتے ہیں، اس لیے سب سے تیز ٹول کامیاب رہتا ہے۔ فرق client-rendered صفحات پر ظاہر ہوتا ہے، جہاں فراہم کردہ HTML ایک خالی shell ہوتا ہے اور متن load کے بعد JavaScript کے ذریعے آتا ہے۔

Draco مختلف tiers میں کام کرتا ہے۔ Tier 0 اور tier 1 کسی بھی JavaScript کے بغیر HTML کو parse کرتے ہیں۔ Tier 2 صفحے کی اپنی JavaScript کو in-process V8 isolate کے اندر چلاتا ہے۔ یہ JavaScript engine ہے جس کے گرد browser موجود نہیں ہوتا، اور README کے مطابق وہاں page code کو host capability bindings حاصل نہیں ہوتیں۔ اس سے browser کی memory کے ایک حصے میں بہت سی single-page applications چل جاتی ہیں۔ جب Draco ایسی رکاوٹ سے ٹکراتا ہے جسے وہ عبور نہیں کر سکتا تو draco scrape code 3 کے ساتھ خارج ہو جاتا ہے، needs_browser۔ اسے scripts میں چیک کریں، کیونکہ zero exit code کے ساتھ خالی file وہ failure ہے جو agent کے context کو خاموشی سے خراب کر دیتا ہے:

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

Firecrawl کا playwright-service حقیقی Chromium چلاتا ہے، اس لیے یہ وہی render کرتا ہے جو browser render کرتا ہے۔ تاہم self-hosted build hosted product کے برابر نہیں ہے: documentation کے مطابق self-hosted instances کو Fire Engine تک رسائی حاصل نہیں ہوتی، اس لیے cloud service کی anti-blocking اور IP rotation دستیاب نہیں ہوتیں، اور /agent اور /browser endpoints unsupported ہیں۔ Hound کو جان بوجھ کر درمیانی طریقے سے بنایا گیا ہے۔ یہ HTTP کے ذریعے fetch کرتا ہے اور ہر request کے مطابق escalation کرتا ہے، جبکہ اس کا warm browser idle timeout کے بعد بند ہو جاتا ہے، اس لیے خاموش server baseline کے قریب رہتا ہے۔

متعین ورژن کے ساتھ Draco انسٹال کریں

README ایک سطری installer درج کرتا ہے۔ اسے shell کو pipe کرنے سے پہلے دیکھیں کہ یہ کیا کرتا ہے: یہ $HOME/.draco/bin/draco میں انسٹال کرتا ہے، ہمیشہ latest release حاصل کرتا ہے، اور کسی signature یا hash کی جانچ نہیں کرتا۔ سرور پر ورژن متعین کریں اور download کی تصدیق کریں۔

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 والی لائن کا مطلب ہے کہ آپ کے پاس موجود bytes وہ نہیں ہیں جو project نے شائع کیے تھے، اس لیے انہیں حذف کرکے دوبارہ شروع کریں۔

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 کو markdown کے طور پر ایک سیکنڈ سے بھی بہت کم وقت میں پرنٹ کرتی ہے۔ 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 شروع کرتے ہی /health جواب دیتا ہے۔ Connection refused کا مطلب ہے کہ یہ listening نہیں کر رہا، اس لیے journalctl -u draco -n 50 پڑھیں۔ عام وجہ یہ ہوتی ہے کہ کوئی دوسرا process پہلے ہی 3002 پر قابض ہے، کیونکہ یہ Firecrawl کا default port بھی ہے، اور --port میں سے کسی ایک کو منتقل کر دیتا ہے۔ Unit files کی مزید تفصیل: systemd service units اور 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"]}'

فَچ ڈیمَن کو public internet سے دور رکھیں

بغیر authentication والا fetch API ایک open proxy ہوتا ہے۔ جو بھی اس port تک پہنچ سکتا ہے، وہ آپ کے server کو آپ کے IP address کے تحت کسی بھی URL کی request بھیجنے پر مجبور کر سکتا ہے۔ Abuse report آپ کے provider کو جائے گی، اس شخص کو نہیں۔ Draco کے دستاویزی serve flags میں API key شامل نہیں ہے، اس لیے تحفظ network کے ذریعے فراہم کرنا ہوگا۔ جب agent اسی box پر چل رہا ہو تو default 127.0.0.1 bind برقرار رکھیں۔ جب agent کسی دوسرے مقام پر ہو تو دونوں سروں کو private tunnel پر رکھیں۔ اپنے زیر انتظام WireGuard VPN معمول کا حل ہے۔ پھر 0.0.0.0 کے بجائے tunnel address پر bind کریں۔ اس کے بعد کسی دوسرے machine سے تصدیق کریں کہ public IP کسی request کا جواب نہیں دیتا۔ ufw firewall کی بنیادی باتیں اور کم سے کم مراعات والے user accounts اس انتظام کے دونوں حصوں کا احاطہ کرتے ہیں۔

کیا آپ کے agent کا code تبدیل ہوگا؟ عملی API compatibility

Draco، Firecrawl v1 کے ان routes کا جواب دیتا ہے: /v1/scrape، /v1/map، /v1/crawl، /v1/batch/scrape اور /v1/search، اور اس کی README میں بتایا گیا ہے کہ نامعلوم fields قبول کر کے نظرانداز کر دی جاتی ہیں۔ جو agent پہلے ہی /v1/scrape پر requests بھیج رہا ہے، اسے صرف نیا base URL درکار ہے؛ اس کے علاوہ کچھ تبدیل نہیں کرنا پڑتا۔ دوسری جانب ہونے والی تبدیلی کو بھی دیکھیں: Firecrawl کا اپنا self-hosting صفحہ اب /v2/crawl کے ذریعے test کرتا ہے، جبکہ موجودہ SDKs v2 استعمال کرتے ہیں۔ اس لیے Draco کو بھیجا گیا v2 client ایسے route کی درخواست کرتا ہے جسے Draco publish نہیں کرتا۔ agent code میں ترمیم کرنے سے پہلے ہر call کو curl کے ذریعے test کریں، اور صرف status code کے بجائے JSON body پڑھیں، کیونکہ ان implementations کے درمیان فرق عموماً field names میں ہوتا ہے۔

robots.txt، rate limits، اور وہ حد جس سے آگے نہیں جانا چاہیے

Draco بطور default robots.txt پڑھتا ہے، اور --ignore-robots اسے بند کرتا ہے۔ Firecrawl بھی یہی default بیان کرتا ہے۔ دونوں کو تبدیل نہ کریں۔ پھر اپنی رفتار مقرر کریں: --delay ہر request کے درمیان milliseconds کا وقفہ رکھتا ہے، جبکہ --max-concurrency متوازی jobs کی تعداد محدود کرتا ہے؛ daemon کا default 8 ہے۔ مشترکہ VPS link پر 2 سے 4 زیادہ مناسب رہتے ہیں اور مجموعی طور پر شاذ ہی سست ہوتے ہیں، کیونکہ rate limiting شروع کرنے والی site آپ سے اتنے اضافی minutes لے سکتی ہے جو concurrency سے بچنے والے وقت سے زیادہ ہوں۔ جو data آپ fetch کریں اسے cache کریں، تاکہ agent کے دوسرے run پر source پر کوئی اضافی بوجھ نہ پڑے۔ یہ AI agent کی لاگت کو کنٹرول کرنے میں سب سے کم خرچ item بھی ہے۔

Challenge walls الگ موضوع ہیں، اور Trawl خاص طور پر اسی مقصد کے لیے بنایا گیا ہے: Cloudflare Turnstile، reCAPTCHA، hCaptcha اور GeeTest۔ Challenge wall کا مطلب صاف الفاظ میں یہ ہے کہ site automated traffic قبول نہیں کر رہی۔ اسے bypass کرنے کی کوشش site کی terms of use کی خلاف ورزی ہو سکتی ہے، اور بعض مقامات پر قانون کی بھی، اس لیے یہ guide صرف fetching infrastructure کا احاطہ کرتی ہے اور وہیں رک جاتی ہے۔ Wall کو عبور کرنے والی یہی techniques site owners کی نگرانی اور blocking کا ہدف بنتی ہیں، اس لیے ان پر بنائی گئی کوئی بھی pipeline غیر مہذب ہونے کے ساتھ ساتھ غیر مستحکم بھی ہوتی ہے۔ جب کوئی source اتنا اہم ہو، تو اس کا RSS feed، public API یا bulk export تلاش کریں۔ ہر طریقہ چلانے میں کم خرچ ہے، اور wall تبدیل ہونے پر ان میں سے کوئی بھی پورے ہفتے کے لیے بند نہیں ہوتا۔

MCP کے ذریعے اسے agent سے مربوط کریں

MCP (model context protocol) وہ interface ہے جسے agent کسی tool کو call کرنے کے لیے استعمال کرتا ہے۔ 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 شائع کرتا ہے، جس تک tunnel کے ذریعے رسائی حاصل کی جاتی ہے۔ Transport کے اختیارات اور expose کی جانے والی چیزوں کے لیے VPS پر MCP servers چلانا دیکھیں۔

Search کے ذریعے pairs حاصل کریں۔ جو agent صرف fetch کر سکتا ہو، وہ اس وقت تک انتظار کرتا ہے جب تک آپ اسے URLs فراہم نہ کریں۔ self-hosted SearXNG search instance شامل کریں، تو وہ خود انہیں تلاش کر سکتا ہے، بالکل اسی طرح جیسے SearXNG پر مبنی browser search skill تلاش کرتا ہے۔ Daemon شروع ہونے کے بعد یہ آپ کے چلائے جانے والے self-hosted AI agents میں سے ہر ایک کے لیے ایک مشترکہ service بن جاتی ہے۔

FAQ

کیا AI agent کے لیے صفحات حاصل کرنے کی خاطر headless browser درکار ہے؟

زیادہ تر صفحات کے لیے نہیں۔ Server-rendered documentation، blogs اور news articles، سادہ HTTP fetch اور HTML-to-markdown مرحلے کے بعد مکمل حالت میں موصول ہو جاتے ہیں۔ Draco اپنے نچلے tiers میں یہی طریقہ استعمال کرتا ہے، اور project کے اپنے اعداد کے مطابق ہر page تقریباً browser-free 300 ms میں حاصل ہوتا ہے۔ Client-rendered applications میں browser کی memory overhead قابلِ جواز ہوتی ہے، کیونکہ فراہم کردہ HTML صرف ایک خالی shell ہوتا ہے۔ Draco کا V8 isolate بغیر browser process کے اس درمیانی صورتِ حال کا بڑا حصہ سنبھال لیتا ہے۔ جب یہ ایسا نہ کر سکے تو یہ code 3، needs_browser، کے ساتھ ختم ہو جاتا ہے۔

VPS پر self-hosted Firecrawl کو کتنی RAM درکار ہوتی ہے؟

اس کی compose file api container کے لیے 8 GB اور Playwright container کے لیے 4 GB کی حد مقرر کرتی ہے۔ یہی stack Redis، RabbitMQ، PostgreSQL اور FoundationDB بھی شروع کرتا ہے۔ 8 GB کے لیے منصوبہ بنائیں۔ 2 GB کی machine پر load کے دوران kernel کا out-of-memory killer containers کو ختم کر دیتا ہے۔ پہلی علامت docker compose ps میں restarted 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 فراہم کرتا ہے۔ یہ ان request fields کو نظرانداز کر دیتا ہے جنہیں یہ نہیں جانتا۔ اس لیے Firecrawl v1 کے خلاف لکھے گئے client کو عموماً صرف نیا base URL درکار ہوتا ہے۔ یہ hosted product نہیں ہے۔ اس کے پیچھے managed proxy pool موجود نہیں، اور Firecrawl کے نئے v2 routes اس کے surface کا حصہ نہیں ہیں۔ اپنے agent کی ہر call کی پہلے curl سے تصدیق کریں۔

کیا scraper کو self-host کرنے کا مطلب ہے کہ میں robots.txt کو نظرانداز کر سکتا ہوں؟

نہیں۔ code کہاں چلتا ہے، اس سے اس بات میں کوئی تبدیلی نہیں آتی کہ site نے کیا شائع کیا ہے یا اس کی terms کیا اجازت دیتی ہیں۔ Draco اور Firecrawl دونوں بطورِ پیش فرض robots.txt کی پابندی کرتے ہیں۔ override flag ان sites کے لیے موجود ہے جو آپ کی اپنی ہوں یا جنہیں crawl کرنے کی آپ کو تحریری اجازت حاصل ہو۔ far end پر rate limits بہرحال نافذ ہوتی ہیں۔ اس لیے کم concurrency کے ساتھ شائستہ --delay آپ کے IP address کو کام کرتے رہنے میں مدد دیتا ہے۔ جو stack صرف challenge wall کو شکست دے کر کام کرتا ہو، وہ بغیر کسی warning کے ناکام ہو سکتا ہے۔