Self-hosted Firecrawl चे सर्वोत्तम पर्याय कोणते?

Self-hosted Firecrawl पर्यायाने काय करणे आवश्यक आहे

Self-hosted Firecrawl पर्यायाचे मुख्य काम एकच आहे: एखादा URL घेणे आणि तो पेज एजंटला वाचता येईल अशा स्वच्छ markdown फॉरमॅटमध्ये परत करणे. होस्ट केलेल्या API मध्ये प्रति पेज शुल्क आकारले जाते, त्यामुळे तुमचा एजंट जितका जास्त माहिती शोधेल तितके बिल वाढत जाते. तुम्ही आधीच पैसे भरत असलेल्या VPS वर हेच काम विनामूल्य होऊ शकते. हे प्रकल्प एका प्रश्नावर विभागले गेले आहेत: तुमच्या सर्व्हरवर headless browser (विंडोशिवाय चालणारे प्रत्यक्ष ब्राउझर इंजिन) सुरू करणे आवश्यक आहे का?

या प्रश्नाचे उत्तर मेमरीचा वापर, प्रत्येक पेजचा खर्च आणि कोणती पेजेस रिकामी मिळतील हे ठरवते. हे मार्गदर्शक Draco, Hound आणि self-hosted Firecrawl रिलीजची तुलना करते, सर्वात हलका पर्याय एका ठराविक व्हर्जनवर इन्स्टॉल करते आणि त्याला MCP (model context protocol) द्वारे एजंटशी जोडते.

चार प्रकल्प आणि प्रत्येकाचे स्वरूप

Draco ही Rust मध्ये लिहिलेली एक बायनरी आहे, जी MIT किंवा Apache-2.0 परवान्याअंतर्गत उपलब्ध आहे. आवृत्ती v0.20.5 ही 16 जुलै 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. तुम्हाला खरी क्रॉल रांग मिळते, परंतु त्यासाठी एक लहान वितरित प्रणाली (distributed system) चालवावी लागते.

Hound हे master-fetch रिपॉझिटरीमध्ये असते आणि PyPI वर hound-mcp म्हणून उपलब्ध आहे. हे MIT परवानाधारक असून 3 ऑगस्ट 2026 पर्यंत याची आवृत्ती 13.0.1 आहे. याला Python 3.11 किंवा त्यापेक्षा नवीन आवृत्तीची आवश्यकता असते. हे प्रथम एक MCP सर्व्हर आहे आणि नंतर एक फेचर आहे: हे साध्या HTTP चा प्रयत्न करते आणि जेव्हा साधे फेच ब्लॉक होते, तेव्हाच Patchright ब्राउझर सुरू करते.

Trawl येथे आहे कारण इतर प्रकल्पांचा शोध घेताना लोक याला भेटतात, आणि हे एक वेगळे काम करते. हे JavaScript आव्हाने आणि CAPTCHAs सोडवण्यासाठी फिंगरप्रिंट-पॅच केलेल्या Firefox चा वापर करते, जे *arr मीडिया स्टॅक मधील FlareSolverr ला पर्याय म्हणून काम करते. हे मार्कडाउन एक्स्ट्रॅक्टर नाही. खालील शिष्टाचारांवरील विभाग हे स्पष्ट करतो की हा फरक तुमच्या एजंट स्टॅकमध्ये याचा समावेश करायचा की नाही, हे का ठरवतो.

ब्राउझर पूलमुळे लहान VPS सर्व्हर्स निकामी का होतात

प्रत्येक उघडा ब्राउझर टॅब हा एक स्वतंत्र रेंडरर प्रोसेस असतो, ज्याचा स्वतःचा DOM (document object model) आणि 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 मधून अचानक गायब होतो आणि ॲप्लिकेशन लॉगमध्ये कोणतीही त्रुटी (error) दिसत नाही. जर तुम्हाला एखादा रीस्टार्ट समजत नसेल, तर त्यानंतर dmesg -T | tail तपासा. संपूर्ण Firecrawl स्टॅकसाठी 8 GB मेमरीचे बजेट ठेवा आणि 4 GB ला टेस्ट-बॉक्ससाठी किमान मर्यादा माना. प्रत्येक सर्व्हिससाठी हे आकडे कसे सेट करायचे, हे memory limits in Docker Compose मध्ये दिले आहे.

ब्राउझरशी संबंधित आणखी एक तांत्रिक बाब अनेकांचा वेळ वाया घालवते. Docker कंटेनरला /dev/shm वर 64 MB ची शेअर केलेली मेमरी (shared memory) देते. Chromium तिथे रेंडरर बफर्स ठेवते, त्यामुळे जड पेजेस लोड होताना ते क्रॅश होते. दोन्ही ब्राउझर स्टॅक्स ही मर्यादा वाढवतात: Hound ची compose फाईल shm_size: "1gb" वापरते. Playwright वापरून तुम्ही तयार केलेल्या कोणत्याही इमेजमध्ये ती ओळ कॉपी करा.

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

स्टॅटिक HTML, सर्व्हर-रेंडर केलेले ब्लॉग, डॉक्युमेंटेशन पेजेस किंवा बातम्यांचे लेख या सर्वांमध्ये जवळजवळ सारखेच markdown मिळते आणि जो सर्वात जलद प्रतिसाद देतो तो यशस्वी ठरतो. फरक क्लायंट-रेंडर केलेल्या पेजेसवर दिसून येतो, जिथे सुरुवातीला मिळणारे HTML हे केवळ एक रिकामे कवच असते आणि मजकूर लोड झाल्यानंतर JavaScript द्वारे येतो.

Draco टप्प्याटप्प्याने प्रगत होते. Tier 0 आणि Tier 1 कोणत्याही JavaScript शिवाय HTML पार्स करतात. Tier 2 पेजची स्वतःची JavaScript एका इन-प्रोसेस V8 isolate मध्ये चालवते. हे एक JavaScript इंजिन आहे ज्याच्या भोवती ब्राउझर नसतो. README मध्ये नमूद केल्याप्रमाणे, पेज कोडला तिथे कोणतीही होस्ट कॅपॅबिलिटी बाइंडिंग मिळत नाही. हे अनेक सिंगल-पेज ॲप्लिकेशन्सना ब्राउझरच्या तुलनेत खूप कमी मेमरीमध्ये हाताळते. जेव्हा Draco ला एखादी अडचण येते जी ती ओलांडू शकत नाही, तेव्हा draco scrape हा needs_browser एक्झिट कोडसह बंद होतो. हे स्क्रिप्ट्समध्ये तपासा, कारण शून्य एक्झिट कोड असलेली रिकामी फाईल ही अशी त्रुटी आहे जी एजंटच्या संदर्भाला (context) हळूवारपणे दूषित करते:

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

Firecrawl ची playwright-service प्रत्यक्ष Chromium चालवते, त्यामुळे ब्राउझर जे रेंडर करतो तेच हे रेंडर करते. सेल्फ-होस्टेड बिल्ड हे होस्ट केलेल्या प्रॉडक्टसारखे नसते: डॉक्युमेंटेशननुसार सेल्फ-होस्टेड इन्स्टन्सना Fire Engine चा ॲक्सेस नसतो, त्यामुळे क्लाउड सर्व्हिसमधील अँटी-ब्लॉकिंग आणि IP रोटेशनची सुविधा उपलब्ध नसते आणि /agent व /browser एंडपॉइंट्सना सपोर्ट नसतो. Hound हे मुद्दामहून या दोघांच्या मध्ये काम करते. ते HTTP द्वारे डेटा मिळवते आणि गरजेनुसार टप्पे वाढवते. त्याचा 'वॉर्म' ब्राउझर आयडल टाइमआऊटनंतर बंद होतो, त्यामुळे एखादा शांत सर्व्हर बेसलाईनच्या जवळच राहतो.

Draco ची विशिष्ट आवृत्ती (pinned version) इंस्टॉल करा

README मध्ये एक-ओळीचा इंस्टॉलर दिला आहे. तो काय करतो हे वाचल्याशिवाय थेट शेलमध्ये पाइप करू नका: तो $HOME/.draco/bin/draco मध्ये इंस्टॉल होतो, तो नेहमी latest रिलीज घेतो आणि तो कोणत्याही स्वाक्षरीची (signature) किंवा हॅशची (hash) तपासणी करत नाही. सर्व्हरवर, आवृत्ती पिन करा आणि डाउनलोडची पडताळणी करा.

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

शेवटची कमांड उदाहरण पृष्ठ (example page) एका सेकंदापेक्षा कमी वेळात मार्कडाउन स्वरूपात प्रिंट करते. 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.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 प्रतिसाद देतो. 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 ला सार्वजनिक इंटरनेटपासून दूर ठेवा

ऑथेंटिकेशन नसलेले fetch API हे एक ओपन प्रॉक्सी असते. ज्या कोणालाही त्या पोर्टपर्यंत पोहोचता येते, तो तुमच्या सर्व्हरचा वापर करून तुमच्या IP ॲड्रेसवरून कोणतीही URL विनंती करू शकतो. अशा गैरवापराची तक्रार तुमच्याकडे येईल, त्या व्यक्तीकडे नाही. Draco च्या दस्तऐवजीकरणानुसार serve फ्लॅग्समध्ये API key चा पर्याय नाही, त्यामुळे नेटवर्क स्तरावरच सुरक्षा राखणे आवश्यक आहे. जेव्हा एजंट त्याच सर्व्हरवर चालत असेल, तेव्हा डीफॉल्ट 127.0.0.1 बाइंडिंग ठेवा. जेव्हा एजंट दुसऱ्या ठिकाणी असेल, तेव्हा दोन्ही टोकांना एका खाजगी टनेलवर ठेवा; यासाठी तुम्ही स्वतः होस्ट केलेले WireGuard VPN हा एक सामान्य उपाय आहे. अशा वेळी 0.0.0.0 ऐवजी टनेलच्या ॲड्रेसवर बाइंड करा. त्यानंतर, दुसऱ्या मशीनवरून तपासा की सार्वजनिक IP वर कोणतीही प्रतिक्रिया मिळत नाही. ufw फायरवॉलची मूलभूत माहिती आणि least privilege युजर अकाउंट्स या दोन गोष्टी या सुरक्षेचे महत्त्वाचे भाग आहेत.

तुमच्या एजंट कोडमध्ये बदल होईल का? प्रत्यक्ष 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 body वाचा, कारण या अंमलबजावणीमध्ये फील्डची नावे वेगळी असू शकतात.

Robots.txt, rate limits आणि मर्यादेत राहणे

Draco डीफॉल्टनुसार robots.txt वाचतो आणि --ignore-robots ते बंद करते. Firecrawl मध्येही हेच डीफॉल्ट असते. दोन्ही सेटिंग्ज तशाच राहू द्या. त्यानंतर तुमचा वेग निश्चित करा: --delay विनंत्यांमध्ये मिलिसेकंदचा कालावधी ठेवते आणि --max-concurrency समांतर कामांची मर्यादा ठरवते, ज्यामध्ये 8 ही डीफॉल्ट संख्या आहे. शेअर केलेल्या VPS लिंकवर 2 ते 4 ही संख्या अधिक योग्य ठरते आणि यामुळे एकूण वेळेत फारसा फरक पडत नाही, कारण जर एखाद्या साईटने तुम्हाला rate limit केले, तर त्यातून बाहेर पडण्यासाठी लागणारा वेळ हा समांतर कामांमुळे वाचलेल्या वेळेपेक्षा जास्त असतो. तुम्ही जे काही मिळवता ते कॅशे (cache) करा, जेणेकरून दुसऱ्यांदा एजंट चालवताना मूळ स्रोतावर कोणताही ताण येणार नाही. AI एजंटच्या खर्चावर नियंत्रण ठेवण्याच्या दृष्टीने हा सर्वात स्वस्त उपाय आहे.

चॅलेंज वॉल्स (Challenge walls) हा एक वेगळा विषय आहे आणि Trawl खास त्यासाठीच बनवले आहे: Cloudflare Turnstile, reCAPTCHA, hCaptcha आणि GeeTest. चॅलेंज वॉल म्हणजे एखादी साईट स्वयंचलित ट्रॅफिकला स्पष्टपणे नाकारत असते. त्याभोवती काम करणे म्हणजे साईटच्या वापर अटींचे उल्लंघन करणे आहे आणि काही ठिकाणी ते कायद्याने गुन्हा ठरू शकते, म्हणून हे मार्गदर्शक फक्त इन्फ्रास्ट्रक्चर मिळवण्यापर्यंतच मर्यादित आहे. ज्या तंत्रांचा वापर करून तुम्ही वॉल पार करता, त्याच तंत्रांवर साईट मालकांचे लक्ष असते आणि ते त्यांना ब्लॉक करतात, ज्यामुळे अशा तंत्रांवर आधारित कोणतीही पाइपलाईन कमकुवत आणि उद्धट ठरते. जेव्हा एखादा स्रोत खूप महत्त्वाचा असतो, तेव्हा त्याचे RSS feed, सार्वजनिक API किंवा बल्क एक्सपोर्ट शोधा. हे चालवण्यासाठी स्वस्त असतात आणि वॉलमध्ये बदल झाल्यावर ते बंद पडत नाहीत.

MCP द्वारे एजंटशी जोडा

MCP (model context protocol) हा असा इंटरफेस आहे ज्याचा वापर एजंट एखादे टूल कॉल करण्यासाठी करतो. Draco मध्ये एकाच बायनरीमध्ये MCP सर्व्हर समाविष्ट असतो, जो stdio द्वारे चालतो:

{ "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 वर एक एंडपॉईंट प्रकाशित करते, ज्यापर्यंत तुम्ही टनेलद्वारे पोहोचू शकता. ट्रान्सपोर्टचे पर्याय आणि काय उघड करायचे (expose) हे VPS वर MCP सर्व्हर चालवणे यामध्ये दिले आहे.

सर्च वापरून पेअर्स मिळवणे. जो एजंट फक्त माहिती मिळवू शकतो, तो तुम्ही URL देण्याची वाट पाहतो. स्वतःचे SearXNG सर्च इंस्टन्स जोडा आणि तो स्वतःहून माहिती शोधू शकेल, जे SearXNG वर आधारित ब्राउझर सर्च स्किल सारखेच आहे. एकदा का डेमन सुरू झाला की, तो तुम्ही चालवत असलेल्या कोणत्याही self-hosted AI एजंट्स साठी एक सामायिक सेवा म्हणून काम करतो.

FAQ

AI एजंटसाठी वेब पेजेस मिळवण्यासाठी मला हेडलेस ब्राउझरची गरज आहे का?

बहुतेक पेजेससाठी याची गरज नाही. सर्व्हर-रेंडर केलेली डॉक्युमेंटेशन, ब्लॉग्स आणि बातम्यांचे लेख साध्या HTTP फेच आणि त्यानंतरच्या HTML-to-markdown प्रक्रियेद्वारे पूर्णपणे मिळतात. प्रकल्पाच्या स्वतःच्या आकडेवारीनुसार, Draco त्याच्या खालच्या टियर्समध्ये प्रति पेज साधारण 300 ms वेळेत ब्राउझरशिवाय हे काम करते. क्लायंट-रेंडर केलेल्या ॲप्लिकेशन्ससाठी ब्राउझरची मेमरी लागते, कारण तिथे मिळालेले HTML हे केवळ एक रिकामे कवच असते. Draco चे V8 isolate ब्राउझर प्रोसेसशिवाय अशा अनेक मध्यम गरजा पूर्ण करते आणि जेव्हा ते शक्य नसते, तेव्हा ते 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 ने करा.

स्क्रॅपर स्वतः होस्ट करणे म्हणजे मी robots.txt कडे दुर्लक्ष करू शकतो का?

नाही. कोड कुठे चालतो, याने एखाद्या वेबसाईटचे प्रकाशन किंवा त्यांच्या अटींमध्ये काहीही बदल होत नाही. Draco आणि Firecrawl दोन्ही डीफॉल्टनुसार robots.txt चे पालन करतात. ज्या वेबसाईटचे तुम्ही मालक आहात किंवा ज्यांना क्रॉल करण्याची तुमच्याकडे लेखी परवानगी आहे, त्यांच्यासाठी ओव्हरराइड फ्लॅग उपलब्ध आहे. रेट लिमिट्स हे समोरच्या सर्व्हरवर लागू असतात, त्यामुळे कमी कॉन्करन्सीसह नम्र --delay वापरल्यास तुमचा IP ॲड्रेस सुरक्षित राहतो. जो स्टॅक केवळ चॅलेंज वॉल (challenge wall) ओलांडून काम करतो, तो स्टॅक कोणत्याही पूर्वसूचनेशिवाय बंद पडू शकतो.