সেরা self-hosted Firecrawl বিকল্প: Draco বনাম Hound
আপনার VPS-এ Draco, Hound এবং Firecrawl-এর তুলনা দেখুন। RAM ব্যবহার, headless browser প্রয়োজনীয়তা এবং API সামঞ্জস্যের ভিত্তিতে সেরা টুলটি বেছে নিন। MCP ইন্টিগ্রেশনসহ বিস্তারিত গাইড।
একটি self-hosted Firecrawl বিকল্পের যা যা করা আবশ্যক
একটি self-hosted Firecrawl বিকল্পের মূল কাজ একটিই: একটি URL গ্রহণ করা এবং সেটিকে পরিষ্কার markdown ফরম্যাটে রূপান্তর করা, যা একটি AI agent পড়তে পারে। hosted API-গুলো প্রতি পৃষ্ঠার জন্য চার্জ করে, তাই আপনার agent যত বেশি তথ্য অনুসন্ধান করবে, খরচ তত বাড়বে। অথচ আপনার ইতিমধ্যে কেনা একটি VPS-এই এই কাজ করা সম্ভব। প্রকল্পগুলো একটি মৌলিক প্রশ্নের ভিত্তিতে বিভক্ত: আপনার সার্ভারে কি একটি headless browser (উইন্ডো ছাড়া চলমান একটি আসল ব্রাউজার ইঞ্জিন) চালু থাকতে হবে?
এই উত্তরের ওপর ভিত্তি করেই নির্ধারিত হয় memory footprint, প্রতিটি পৃষ্ঠার খরচ এবং কোন পৃষ্ঠাগুলো খালি আসবে। এই নির্দেশিকাটি Draco, Hound এবং self-hosted Firecrawl release-এর তুলনা করে, সবচেয়ে হালকা সংস্করণটি একটি নির্দিষ্ট ভার্সনে ইনস্টল করে এবং সেটিকে 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 সার্ভার এবং দ্বিতীয়ত একটি ফেচার: এটি প্রথমে সাধারণ HTTP ব্যবহার করে এবং শুধুমাত্র সাধারণ ফেচ ব্লক হলে Patchright ব্রাউজার চালু করে।
Trawl এখানে অন্তর্ভুক্ত কারণ অন্যগুলোর খোঁজে থাকা মানুষজন প্রায়ই এর মুখোমুখি হন, কিন্তু এটি ভিন্ন কাজ করে। এটি একটি ফিঙ্গারপ্রিন্ট-প্যাচড Firefox ব্যবহার করে JavaScript চ্যালেঞ্জ এবং CAPTCHA সমাধান করে, যা একটি *arr মিডিয়া স্ট্যাকে FlareSolverr-এর বিকল্প হিসেবে কাজ করে। এটি কোনো মার্কডাউন এক্সট্রাক্টর নয়। নিচের শিষ্টাচার সংক্রান্ত অংশে ব্যাখ্যা করা হয়েছে কেন এই পার্থক্যটি নির্ধারণ করে যে এটি আপনার এজেন্ট স্ট্যাকে আদৌ থাকা উচিত কি না।
কেন ব্রাউজার পুল ছোট VPS সার্ভারের জন্য ঝুঁকিপূর্ণ
প্রতিটি খোলা ব্রাউজার ট্যাব একটি আলাদা রেন্ডারার প্রসেস, যার নিজস্ব DOM (document object model) এবং JavaScript heap থাকে। তাই মেমরির ব্যবহার নির্ভর করে একই সময়ে খোলা থাকা পেজের সংখ্যার ওপর, প্রতিদিন কতগুলো পেজ ফেচ করা হচ্ছে তার ওপর নয়। এই প্রজেক্টগুলোর মধ্যে দুটি তাদের নিজস্ব compose ফাইলে এই খরচের বিষয়টি উল্লেখ করেছে।
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 অন্তর্ভুক্ত থাকে। এগুলো প্রজেক্টগুলোর নির্ধারিত সর্বোচ্চ সীমা; এগুলো কোনো অলস সিস্টেমের পরিমাপ নয়, বরং প্রকাশিত পরিসংখ্যান। এছাড়া Firecrawl-এর এই সংখ্যার বাইরেও Redis, RabbitMQ, PostgreSQL এবং FoundationDB-এর জন্য আলাদা মেমরি প্রয়োজন হয়।
আপনার সার্ভারের মোট 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-নির্ভর পেজে এক্সট্রাকশনের মান
স্ট্যাটিক HTML, সার্ভার-রেন্ডার করা ব্লগ, ডকুমেন্টেশন পেজ বা নিউজ আর্টিকেলের ক্ষেত্রে সার্ভার থেকে প্রায় একই রকম markdown পাওয়া যায় এবং দ্রুততমটিই সেরা ফলাফল দেয়। পার্থক্যটি বোঝা যায় client-rendered পেজের ক্ষেত্রে, যেখানে সার্ভার থেকে আসা HTML একটি খালি শেল মাত্র এবং লোড হওয়ার পর JavaScript-এর মাধ্যমে টেক্সট কন্টেন্ট আসে।
Draco ধাপে ধাপে তার সক্ষমতা বাড়ায়। Tier 0 এবং Tier 1 কোনো JavaScript ছাড়াই HTML পার্স করে। Tier 2 পেজের নিজস্ব JavaScript-কে একটি in-process V8 isolate-এর ভেতরে চালায়; এটি হলো ব্রাউজারবিহীন একটি JavaScript ইঞ্জিন। README অনুযায়ী, সেখানে পেজের কোড কোনো host capability binding পায় না। এটি ব্রাউজারের তুলনায় অনেক কম মেমোরি ব্যবহার করে অধিকাংশ single-page application-এর কাজ সম্পন্ন করতে পারে। Draco যখন এমন কোনো বাধার সম্মুখীন হয় যা সে অতিক্রম করতে পারে না, তখন draco scrape কোড 3, needs_browser নিয়ে এক্সিট করে। স্ক্রিপ্টে এটি চেক করুন, কারণ জিরো এক্সিট কোডসহ একটি খালি ফাইল এমন এক ব্যর্থতা যা নীরবে এজেন্টের কনটেক্সটকে নষ্ট করে দেয়:
draco scrape https://example.com > page.md
echo "exit=$?"Firecrawl-এর playwright-service একটি আসল Chromium চালায়, তাই ব্রাউজার যা রেন্ডার করে এটিও তাই করে। তবে self-hosted বিল্ডটি ক্লাউড-ভিত্তিক প্রোডাক্টের মতো নয়: ডকুমেন্টেশন অনুযায়ী self-hosted ইনস্ট্যান্সগুলোর Fire Engine-এ কোনো অ্যাক্সেস নেই। ফলে ক্লাউড সার্ভিসের anti-blocking এবং IP rotation সুবিধাগুলো এখানে অনুপস্থিত এবং /agent ও /browser এন্ডপয়েন্টগুলো সমর্থিত নয়। Hound ইচ্ছাকৃতভাবেই এই দুটির মাঝামাঝি অবস্থানে থাকে। এটি HTTP-এর মাধ্যমে ডেটা ফেচ করে এবং প্রতি রিকোয়েস্ট অনুযায়ী সক্ষমতা বাড়ায়। এর warm browser একটি idle timeout-এর পর বন্ধ হয়ে যায়, ফলে একটি অলস সার্ভার baseline-এর কাছাকাছি থাকে।
একটি নির্দিষ্ট ভার্সনসহ 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 কোনো সাজসজ্জা নয়: আর্কাইভ লেআউটটি প্রজেক্টের পাবলিক কন্ট্রাক্টের অংশ নয় এবং অফিসিয়াল ইনস্টলার একই উপায়ে বাইনারিটি খুঁজে বের করে।
আপনার লগইন ইউজারের পরিবর্তে ডেমোনটিকে তার নিজস্ব অ্যাকাউন্টের অধীনে চালান। /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.targetsudo 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 উত্তর দেয়। 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-এ পৌঁছাতে পারলে আপনার সার্ভারকে আপনার IP address ব্যবহার করে যেকোনো URL-এ অনুরোধ পাঠাতে বাধ্য করতে পারে। এর ফলে অপব্যবহারের রিপোর্ট আপনার কাছে আসবে, তাদের কাছে নয়। 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 ব্যবহার করে। তাই একটি v2 ক্লায়েন্ট যখন Draco-এর দিকে নির্দেশ করা হয়, তখন সেটি এমন একটি রুট খোঁজে যা Draco প্রকাশ করে না। এজেন্টের কোড সম্পাদনা করার আগে curl দিয়ে প্রতিটি কল পরীক্ষা করুন। স্ট্যাটাস কোডের পরিবর্তে JSON বডি পড়ুন, কারণ ফিল্ডের নামগুলোই সেই জায়গা যেখানে এই ইমপ্লিমেন্টেশনগুলোর মধ্যে পার্থক্য তৈরি হয়।
Robots.txt, rate limits, এবং যে সীমারেখা অতিক্রম করা উচিত নয়
Draco ডিফল্টভাবে robots.txt পড়ে এবং --ignore-robots তা বন্ধ করে দেয়। Firecrawl-এর ক্ষেত্রেও একই ডিফল্ট নিয়ম প্রযোজ্য। উভয়ই অপরিবর্তিত রাখুন। এরপর আপনার নিজের গতি নির্ধারণ করুন: --delay অনুরোধগুলোর মাঝে মিলিসেকেন্ডের বিরতি দেয় এবং --max-concurrency সমান্তরাল কাজের সীমা নির্ধারণ করে, যেখানে ডেমনের ডিফল্ট মান 8। একটি শেয়ারড VPS লিংকের জন্য 2 থেকে 4টি কাজ রাখা বেশি নিরাপদ এবং এতে সামগ্রিক গতি খুব একটা কমে না, কারণ কোনো সাইট যদি আপনাকে rate limit করতে শুরু করে, তবে তা concurrency থেকে প্রাপ্ত সময়ের চেয়ে অনেক বেশি সময় নষ্ট করবে। যা সংগ্রহ করছেন তা ক্যাশ (cache) করুন, যাতে দ্বিতীয়বার এজেন্ট চালালে মূল সোর্সের ওপর কোনো চাপ না পড়ে। এটি AI এজেন্টের খরচ নিয়ন্ত্রণ করার ক্ষেত্রে সবচেয়ে সাশ্রয়ী উপায়।
চ্যালেঞ্জ ওয়াল একটি ভিন্ন বিষয় এবং Trawl ঠিক সেই কাজের জন্যই তৈরি: Cloudflare Turnstile, reCAPTCHA, hCaptcha এবং GeeTest। একটি চ্যালেঞ্জ ওয়াল হলো কোনো সাইটের সরাসরি স্বয়ংক্রিয় ট্রাফিক প্রত্যাখ্যান করা। এটি এড়িয়ে চলার চেষ্টা করা সাইটের ব্যবহারের শর্তাবলির পরিপন্থী এবং কিছু ক্ষেত্রে বেআইনি, তাই এই নির্দেশিকাটি শুধুমাত্র fetching infrastructure পর্যন্ত সীমাবদ্ধ। যে কৌশলগুলো ব্যবহার করে ওয়াল পার হওয়া যায়, সাইটের মালিকরা ঠিক সেই কৌশলগুলোর ওপরই নজর রাখেন এবং ব্লক করেন, যা এমন কোনো পাইপলাইনকে ভঙ্গুর এবং অভদ্র করে তোলে। যখন কোনো সোর্স অত্যন্ত গুরুত্বপূর্ণ হয়, তখন সেটির RSS feed, পাবলিক API বা bulk export খুঁজুন। এগুলোর প্রতিটি চালানো সাশ্রয়ী এবং ওয়াল পরিবর্তিত হলেও এগুলো অকেজো হয়ে যায় না।
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 সরবরাহের জন্য অপেক্ষা করে। একটি সেলফ-হোস্টেড SearXNG সার্চ ইনস্ট্যান্স যোগ করুন এবং এটি নিজেই সেগুলো খুঁজে বের করতে পারবে, যা SearXNG-এর ওপর ভিত্তি করে তৈরি ব্রাউজার সার্চ স্কিল-এর মতোই। ডেমোনটি চালু হয়ে গেলে, এটি আপনার চালানো যেকোনো সেলফ-হোস্টেড AI এজেন্ট-এর জন্য একটি শেয়ার্ড সার্ভিস হিসেবে কাজ করে।
FAQ
AI agent-এর জন্য পেজ ফেচ করতে আমার কি headless browser প্রয়োজন?
অধিকাংশ পেজের জন্য প্রয়োজন নেই। সার্ভার-রেন্ডার করা ডকুমেন্টেশন, ব্লগ এবং নিউজ আর্টিকেল সাধারণ HTTP ফেচ এবং HTML-to-markdown ধাপের মাধ্যমেই সম্পূর্ণ পাওয়া যায়। Draco-এর লোয়ার টায়ারে প্রজেক্টের নিজস্ব হিসাব অনুযায়ী প্রতি পেজের জন্য প্রায় 300 ms সময় লাগে, যেখানে কোনো ব্রাউজারের প্রয়োজন হয় না। ক্লায়েন্ট-রেন্ডার করা অ্যাপ্লিকেশনের ক্ষেত্রে ব্রাউজার মেমোরি খরচ করে, কারণ সেখানে ডেলিভার করা HTML একটি খালি শেল মাত্র। Draco-এর V8 isolate কোনো ব্রাউজার প্রসেস ছাড়াই সেই মধ্যবর্তী অবস্থার বেশিরভাগ অংশ কভার করে। যখন এটি কাজ করতে পারে না, তখন এটি কোড 3, needs_browser, নিয়ে এক্সিট করে।
একটি 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 অ্যাড্রেসকে সচল রাখবে। যে স্ট্যাক শুধুমাত্র চ্যালেঞ্জ ওয়াল অতিক্রম করেই কাজ করে, সেই স্ট্যাক যেকোনো সময় সতর্কবার্তা ছাড়াই অকেজো হয়ে যেতে পারে।