SSD Nodes Learn Hosting plans →
নির্দেশিকা Matt Connorদ্বারা Matt Connor · আপডেট করা হয়েছে 2026-08-27

সেরা self-hosted Firecrawl বিকল্প: Draco ও Hound তুলনা

আপনার VPS-এ Draco, Hound এবং self-hosted Firecrawl ব্যবহারের তুলনা দেখুন। RAM ব্যবহার, headless browser প্রয়োজনীয়তা এবং MCP কানেক্টিভিটিসহ বিস্তারিত গাইড এখানে দেওয়া হলো।

একটি self-hosted Firecrawl বিকল্পের যা করা আবশ্যক

একটি self-hosted Firecrawl বিকল্পের মূল কাজ হলো একটি URL গ্রহণ করা এবং সেটিকে পরিষ্কার markdown ফরম্যাটে রূপান্তর করা, যা একটি AI agent পড়তে পারে। hosted API-গুলো প্রতি পৃষ্ঠার জন্য চার্জ করে, তাই আপনার agent যত বেশি তথ্য অনুসন্ধান করবে, খরচ তত বাড়বে। অথচ আপনার ইতিমধ্যে কেনা একটি VPS-এই এই কাজটি করা সম্ভব। এই প্রজেক্টগুলো একটি মৌলিক প্রশ্নের ওপর ভিত্তি করে বিভক্ত: আপনার সার্ভারে কি একটি headless browser (উইন্ডো ছাড়া চলমান একটি আসল ব্রাউজার ইঞ্জিন) চালু থাকতে হবে?

এই উত্তরের ওপর নির্ভর করে মেমোরি ব্যবহারের পরিমাণ, প্রতি পৃষ্ঠার খরচ এবং কোন পৃষ্ঠাগুলো খালি আসবে। এই নির্দেশিকাটি Draco, Hound এবং self-hosted Firecrawl রিলিজের তুলনা করে, একটি নির্দিষ্ট ভার্সন ইনস্টল করে এবং সেটিকে MCP (model context protocol)-এর মাধ্যমে একটি agent-এর সাথে সংযুক্ত করে।

চারটি প্রজেক্ট এবং প্রতিটি আসলে কী

Draco হলো Rust-এ লেখা একটি বাইনারি, যা MIT বা Apache-2.0 লাইসেন্সের অধীনে প্রকাশিত। 16 জুলাই 2026 তারিখে v0.20.5 রিলিজটি প্রকাশিত হয়। 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। আপনি একটি ছোট ডিস্ট্রিবিউটেড সিস্টেম চালানোর বিনিময়ে প্রকৃত ক্রল কিউ (crawl queue) সুবিধা পান।

Hound প্রজেক্টটি master-fetch রিপোজিটরিতে থাকে এবং hound-mcp হিসেবে PyPI-তে সরবরাহ করা হয়। এটি MIT লাইসেন্সভুক্ত এবং 3 আগস্ট 2026 অনুযায়ী এর সংস্করণ 13.0.1। এর জন্য Python 3.11 বা তার চেয়ে নতুন সংস্করণ প্রয়োজন। এটি মূলত একটি MCP সার্ভার এবং দ্বিতীয়ত একটি ফেচার (fetcher): এটি প্রথমে সাধারণ HTTP ব্যবহার করে এবং শুধুমাত্র সাধারণ ফেচ ব্লক হলে Patchright ব্রাউজার চালু করে।

Trawl এখানে অন্তর্ভুক্ত কারণ অন্যগুলো খোঁজার সময় মানুষ এটির মুখোমুখি হয়, কিন্তু এটি ভিন্ন কাজ করে। এটি একটি ফিঙ্গারপ্রিন্ট-প্যাচড Firefox ব্যবহার করে JavaScript চ্যালেঞ্জ এবং CAPTCHA সমাধান করে, যা একটি *arr মিডিয়া স্ট্যাকে FlareSolverr-এর বিকল্প হিসেবে কাজ করে। এটি কোনো মার্কডাউন এক্সট্রাক্টর নয়। নিচের শিষ্টাচার বিষয়ক সেকশনে ব্যাখ্যা করা হয়েছে কেন এই পার্থক্যটি নির্ধারণ করে যে এটি আপনার এজেন্ট স্ট্যাকে আদৌ থাকা উচিত কি না।

কেন ব্রাউজার পুল ছোট VPS সার্ভারের জন্য ঝুঁকিপূর্ণ

প্রতিটি খোলা ব্রাউজার ট্যাব একটি আলাদা রেন্ডারার প্রসেস হিসেবে কাজ করে, যার নিজস্ব DOM (document object model) এবং JavaScript heap থাকে। তাই মেমরির ব্যবহার নির্ভর করে একই সময়ে খোলা থাকা পৃষ্ঠার সংখ্যার ওপর, প্রতিদিন মোট কতগুলো পৃষ্ঠা লোড করা হয়েছে তার ওপর নয়। এই প্রজেক্টগুলোর মধ্যে দুটি তাদের নিজস্ব compose ফাইলে এই খরচের বিষয়টি উল্লেখ করেছে।

ChartMemory ceilings each project sets in its own compose file (GB)
The data behind this chart
[
  {
    "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 ফাইল একটি কন্টেইনারের জন্য 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-নির্ভর পেজগুলোতে এক্সট্রাকশন কোয়ালিটি

স্ট্যাটিক HTML, সার্ভার-রেন্ডার করা ব্লগ, ডকুমেন্টেশন পেজ বা নিউজ আর্টিকেলের ক্ষেত্রে সব টুলই প্রায় একই রকম Markdown প্রদান করে এবং দ্রুততম টুলটিই সেরা ফলাফল দেয়। পার্থক্যটি দেখা যায় ক্লায়েন্ট-রেন্ডার করা পেজগুলোর ক্ষেত্রে, যেখানে প্রাথমিক HTML একটি খালি শেল হিসেবে আসে এবং পেজ লোড হওয়ার পর JavaScript-এর মাধ্যমে টেক্সট কন্টেন্ট যুক্ত হয়।

Draco ধাপে ধাপে তার সক্ষমতা বাড়ায়। Tier 0 এবং Tier 1 কোনো JavaScript ছাড়াই HTML পার্স করে। Tier 2 পেজের নিজস্ব JavaScript-কে একটি ইন-প্রসেস V8 isolate-এর ভেতরে চালায়; এটি হলো ব্রাউজারবিহীন একটি JavaScript ইঞ্জিন। README অনুযায়ী, সেখানে পেজের কোড কোনো হোস্ট ক্যাপাবিলিটি বাইন্ডিং পায় না। এটি ব্রাউজারের তুলনায় অনেক কম মেমোরি ব্যবহার করে অধিকাংশ সিঙ্গেল-পেজ অ্যাপ্লিকেশন (SPA) হ্যান্ডেল করতে পারে। Draco যখন এমন কোনো বাধার সম্মুখীন হয় যা সে অতিক্রম করতে পারে না, তখন draco scrape 3 কোড নিয়ে এক্সিট করে, যা needs_browser। স্ক্রিপ্টে এটি চেক করুন, কারণ জিরো এক্সিট কোডসহ একটি খালি ফাইল এমন এক ব্যর্থতা যা নীরবে এজেন্টের কনটেক্সটকে নষ্ট করে দেয়:

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

Firecrawl-এর playwright-service একটি প্রকৃত Chromium চালায়, তাই এটি ব্রাউজারের মতোই পেজ রেন্ডার করে। সেলফ-হোস্টেড বিল্ড মানেই ক্লাউড প্রোডাক্ট নয়: ডকুমেন্টেশন অনুযায়ী সেলফ-হোস্টেড ইনস্ট্যান্সগুলোর Fire Engine-এ কোনো অ্যাক্সেস নেই, তাই ক্লাউড সার্ভিসের অ্যান্টি-ব্লকিং এবং IP রোটেশন সুবিধা এখানে অনুপস্থিত, এবং /agent ও /browser এন্ডপয়েন্টগুলো এখানে সমর্থিত নয়। Hound ইচ্ছাকৃতভাবেই এই দুটির মাঝামাঝি অবস্থানে থাকে। এটি HTTP-এর মাধ্যমে ডেটা ফেচ করে এবং প্রতি রিকোয়েস্ট অনুযায়ী সক্ষমতা বাড়ায়। এর ওয়ার্ম ব্রাউজার একটি নির্দিষ্ট সময় নিষ্ক্রিয় থাকার পর বন্ধ হয়ে যায়, ফলে একটি শান্ত সার্ভার বেসলাইনের কাছাকাছি থাকে।

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 কোনো সাজসজ্জা নয়: আর্কাইভ লেআউটটি প্রজেক্টের পাবলিক কন্ট্রাক্টের অংশ নয় এবং অফিসিয়াল ইনস্টলার একই উপায়ে বাইনারিটি খুঁজে বের করে।

আপনার লগইন ইউজারের পরিবর্তে daemon-টিকে তার নিজস্ব অ্যাকাউন্টের অধীনে চালান। /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 লিসেনিং মোডে আসার সাথে সাথে /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 হিসেবে কাজ করে। যে কেউ এই port-এ পৌঁছাতে পারলে আপনার সার্ভারকে দিয়ে যেকোনো URL-এ অনুরোধ পাঠাতে পারবে, আর এর ফলে আসা abuse report আপনার provider-এর কাছে যাবে, তাদের কাছে নয়। Draco-এর নথিবদ্ধ serve flag-এ কোনো API key-এর উল্লেখ নেই, তাই সুরক্ষার জন্য নেটওয়ার্কের ওপর নির্ভর করতে হবে। agent যখন একই সার্ভারে চলে, তখন ডিফল্ট 127.0.0.1 bind ব্যবহার করুন। agent যখন অন্য কোথাও থাকে, তখন উভয় প্রান্তকে একটি private tunnel-এর ভেতর রাখুন; আপনার নিজের হোস্ট করা WireGuard VPN এক্ষেত্রে সাধারণ সমাধান, এবং 0.0.0.0-এর পরিবর্তে tunnel address-এ bind করুন। এরপর অন্য একটি মেশিন থেকে পরীক্ষা করে দেখুন যে public IP কোনো সাড়া দিচ্ছে কি না। ufw firewall-এর মৌলিক বিষয়সমূহ এবং least privilege user account এই সুরক্ষার দুটি দিক কভার করে।

আপনার এজেন্টের কোড কি পরিবর্তিত হবে? বাস্তবে 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 সমান্তরাল কাজের সীমা নির্ধারণ করে, যেখানে ডেমনের ডিফল্ট মান হলো 8। একটি শেয়ারড VPS লিংকের জন্য দুই থেকে চার হলো নিরাপদ সীমা এবং এতে সামগ্রিক গতি খুব একটা কমে না, কারণ কোনো সাইট যদি আপনাকে rate limit করতে শুরু করে, তবে তা সমান্তরাল কাজের মাধ্যমে বাঁচানো সময়ের চেয়ে অনেক বেশি সময় নষ্ট করে। যা সংগ্রহ করছেন তা ক্যাশ (cache) করে রাখুন, যাতে দ্বিতীয়বার এজেন্ট চালালে মূল সাইটের ওপর কোনো চাপ না পড়ে। এটি AI এজেন্টের খরচ নিয়ন্ত্রণ করার ক্ষেত্রে সবচেয়ে সাশ্রয়ী উপায়।

চ্যালেঞ্জ ওয়াল একটি ভিন্ন বিষয় এবং Trawl বিশেষভাবে এর জন্যই তৈরি: Cloudflare Turnstile, reCAPTCHA, hCaptcha এবং GeeTest। একটি চ্যালেঞ্জ ওয়াল হলো সহজ কথায় কোনো সাইটের স্বয়ংক্রিয় ট্রাফিক প্রত্যাখ্যান করা। এটি এড়িয়ে চলার চেষ্টা করা সাইটের ব্যবহারের শর্তাবলির পরিপন্থী এবং কিছু জায়গায় আইনেরও লঙ্ঘন হতে পারে, তাই এই নির্দেশিকাটি শুধুমাত্র অবকাঠামো সংগ্রহ (fetching infrastructure) পর্যন্তই সীমাবদ্ধ। যে কৌশলগুলো ব্যবহার করে ওয়াল পার হওয়া যায়, সাইটের মালিকরা ঠিক সেই কৌশলগুলোর ওপরই নজর রাখেন এবং ব্লক করেন, যা এ ধরনের পাইপলাইনকে ভঙ্গুর এবং অভদ্র করে তোলে। যখন কোনো উৎস আপনার কাছে অত্যন্ত গুরুত্বপূর্ণ হয়, তখন সেটির RSS feed, পাবলিক API বা বাল্ক এক্সপোর্ট (bulk export) খোঁজার চেষ্টা করুন। এগুলোর প্রতিটি চালানো সাশ্রয়ী এবং ওয়ালের কোনো পরিবর্তন হলে এগুলো অকেজো হয়ে যায় না।

MCP-এর মাধ্যমে একটি এজেন্টের সাথে সংযুক্ত করুন

MCP (model context protocol) হলো কোনো agent-এর tool কল করার interface। কোন tool আদৌ model-এর কাছে পৌঁছাবে এবং আপনার অনুমতি না নিয়ে agent সেটি কল করতে পারবে কি না, তা এক ধাপ ওপরে থাকা যে harness-এর ভিতরে model চলে সেটি নির্ধারণ করে। তাই daemon-কে listening অবস্থায় আনা wiring-এর মাত্র অর্ধেক। Draco একই binary-র মধ্যে stdio ব্যবহার করে একটি MCP server চালায়:

{ "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-এর জন্য পেজ ফেচ করতে কি আমার headless browser প্রয়োজন?

অধিকাংশ পেজের ক্ষেত্রে প্রয়োজন নেই। সার্ভার-রেন্ডার করা ডকুমেন্টেশন, ব্লগ এবং খবরের নিবন্ধগুলো সাধারণ HTTP ফেচ এবং HTML-থেকে-markdown রূপান্তরের মাধ্যমেই সম্পূর্ণ পাওয়া যায়। প্রকল্পের নিজস্ব পরিসংখ্যান অনুযায়ী, Draco-এর লোয়ার টায়ারে প্রতি পেজের জন্য প্রায় 300 ms সময় লাগে, যেখানে কোনো ব্রাউজারের প্রয়োজন হয় না। ক্লায়েন্ট-রেন্ডার করা অ্যাপ্লিকেশনের ক্ষেত্রে ব্রাউজার মেমোরি খরচ করে, কারণ সেখানে প্রাপ্ত HTML একটি খালি শেল মাত্র। Draco-এর V8 isolate ব্রাউজার প্রসেস ছাড়াই এই মধ্যবর্তী অনেক কাজ সম্পন্ন করে এবং যখন এটি পারে না, তখন এটি needs_browser কোড 3 নিয়ে বন্ধ হয়ে যায়।

একটি VPS-এ self-hosted Firecrawl চালানোর জন্য কতটুকু RAM প্রয়োজন?

এর compose ফাইলে api কন্টেইনারের জন্য 8 GB এবং Playwright কন্টেইনারের জন্য 4 GB মেমোরি লিমিট সেট করা থাকে। একই স্ট্যাকে Redis, RabbitMQ, PostgreSQL এবং FoundationDB-ও চালু হয়। তাই 8 GB RAM-এর পরিকল্পনা রাখুন। 2 GB-এর বক্সে লোড বাড়লে কার্নেলের out-of-memory killer কন্টেইনারগুলোকে বন্ধ করে দেয়। এর প্রথম লক্ষণ হলো docker compose ps-এ কন্টেইনার রিস্টার্ট হওয়া, যেখানে অ্যাপ্লিকেশন লগে কোনো কার্যকর তথ্য থাকে না। তাই dmesg -T | tail দিয়ে এটি নিশ্চিত করুন।

Draco কি Firecrawl API-এর সরাসরি বিকল্প?

v1 এন্ডপয়েন্টের ক্ষেত্রে এটি বেশ কাছাকাছি। এটি /v1/scrape, /v1/map, /v1/crawl, /v1/batch/scrape এবং /v1/search সাপোর্ট করে এবং অজানা রিকোয়েস্ট ফিল্ডগুলোকে উপেক্ষা করে। তাই Firecrawl v1-এর জন্য লেখা কোনো ক্লায়েন্টের সাধারণত শুধু একটি নতুন base URL প্রয়োজন হয়। এটি হোস্ট করা পণ্যটির মতো নয়: এর পেছনে কোনো ম্যানেজড প্রক্সি পুল নেই এবং Firecrawl-এর নতুন v2 রুটগুলো এর অন্তর্ভুক্ত নয়। আপনার এজেন্ট যে কলগুলো করে, তা প্রথমে curl দিয়ে যাচাই করে নিন।

স্ক্র্যাপার self-host করার মানে কি আমি robots.txt উপেক্ষা করতে পারি?

না। কোড কোথায় চলছে তার ওপর ভিত্তি করে সাইট কী প্রকাশ করেছে বা তাদের শর্তাবলীতে কী অনুমতি দেওয়া আছে, তা পরিবর্তিত হয় না। Draco এবং Firecrawl উভয়ই ডিফল্টভাবে robots.txt মেনে চলে। আপনার নিজের সাইট বা যে সাইট ক্রল করার লিখিত অনুমতি আপনার আছে, তার জন্য override ফ্ল্যাগ ব্যবহার করা যায়। রেট লিমিট সব ক্ষেত্রেই কার্যকর থাকে, তাই কম কনকারেন্সিসহ একটি মার্জিত --delay আপনার IP অ্যাড্রেসকে সচল রাখবে। যে স্ট্যাক শুধুমাত্র চ্যালেঞ্জ ওয়াল অতিক্রম করার মাধ্যমেই কাজ করে, তা যেকোনো সময় সতর্কবার্তা ছাড়াই অকেজো হয়ে যেতে পারে।