சுயமாக இயங்கும் Firecrawl மாற்றுகள்: VPS-ல் நிறுவுவது

சுயமாக இயங்கும் Firecrawl மாற்றமைப்பிற்கான தேவைகள்

சுயமாக இயங்கும் (self-hosted) Firecrawl மாற்றமைப்பிற்கு ஒரே ஒரு பணிதான் உள்ளது: ஒரு URL-ஐப் பெற்று, அதை ஒரு agent வாசிக்கக்கூடிய வகையில் சுத்தமான markdown கோப்பாக மாற்றிக் கொடுக்க வேண்டும். Hosted API-கள் ஒவ்வொரு பக்கத்திற்கும் கட்டணம் வசூலிக்கின்றன, எனவே உங்கள் agent-ன் தேடல் அதிகரிக்க அதிகரிக்க கட்டணமும் உயரும். ஆனால், நீங்கள் ஏற்கனவே பணம் செலுத்திப் பயன்படுத்தும் VPS-லேயே இந்த வேலையைச் செய்ய முடியும். இந்தத் திட்டங்கள் ஒரு முக்கியமான கேள்வியின் அடிப்படையில் பிரிகின்றன: ஒரு headless browser (திரையில் தெரியாத, பின்னணியில் இயங்கும் உண்மையான browser engine) உங்கள் server-ல் இயங்க வேண்டுமா?

இந்தக் கேள்விக்கான பதில்தான் memory பயன்பாடு, ஒவ்வொரு பக்கத்திற்கான செலவு மற்றும் எந்தெந்தப் பக்கங்கள் காலியாக வருகின்றன என்பதைத் தீர்மானிக்கிறது. இந்த வழிகாட்டி Draco, Hound மற்றும் சுயமாக இயங்கும் Firecrawl release ஆகியவற்றை ஒப்பிடுகிறது. இதில் மிகக் குறைந்த வளங்களைப் பயன்படுத்தும் ஒன்றை ஒரு குறிப்பிட்ட version-ல் நிறுவி, அதை MCP (model context protocol) மூலம் ஒரு agent-உடன் இணைக்கிறது.

நான்கு திட்டங்கள் மற்றும் ஒவ்வொன்றின் உண்மையான பணி

Draco என்பது Rust மொழியில் எழுதப்பட்ட ஒரு binary ஆகும். இது MIT அல்லது Apache-2.0 உரிமத்தின் கீழ் உள்ளது. இதன் v0.20.5 release 16 ஜூலை 2026 அன்று வெளியிடப்பட்டது. draco scrape <url> markdown-ஐ stdout-க்கு அச்சிடுகிறது. draco serve என்பது Firecrawl பயன்படுத்தும் 127.0.0.1:3002 port-ல் பதிலளிக்கும் ஒரு daemon-ஐ இயக்குகிறது. இது எந்த container image-ஐயும் கொண்டிருக்கவில்லை, எந்த browser-ஐயும் தொடங்குவதில்லை.

Firecrawl self-hosted என்பது hosted product-ன் பின்னணியில் உள்ள engine ஆகும். இது AGPL-3.0 உரிமத்தின் கீழ் உள்ளது. இதன் docker-compose.yaml ஏழு சேவைகளை வரையறுக்கிறது: playwright-service, api, redis, rabbitmq, nuq-postgres, foundationdb மற்றும் foundationdb-init. ஒரு சிறிய distributed system-ஐ இயக்குவதன் மூலம் நீங்கள் உண்மையான crawl queue-ஐப் பெறலாம்.

Hound என்பது master-fetch repository-ல் உள்ளது. இது hound-mcp என்ற பெயரில் PyPI-க்கு அனுப்பப்படுகிறது. இது MIT உரிமம் பெற்றது. 3 ஆகஸ்ட் 2026 நிலவரப்படி இதன் பதிப்பு 13.0.1 ஆகும். இதற்கு Python 3.11 அல்லது அதற்குப் பிந்தைய பதிப்பு தேவை. இது முதலில் ஒரு MCP server, இரண்டாவதாகவே ஒரு fetcher: இது சாதாரண HTTP-ஐ முயற்சிக்கும்; சாதாரண fetch தடுக்கப்பட்டால் மட்டுமே Patchright browser-ஐத் தொடங்கும்.

Trawl இங்கே குறிப்பிடப்படக் காரணம், மற்றவற்றைத் தேடும்போது மக்கள் இதையும் எதிர்கொள்கிறார்கள், ஆனால் இது வேறு ஒரு பணியைச் செய்கிறது. இது ஒரு *arr media stack-ல் FlareSolverr-க்கு மாற்றாக, fingerprint-patched Firefox மூலம் JavaScript சவால்கள் மற்றும் CAPTCHA-க்களைத் தீர்க்கிறது. இது ஒரு markdown extractor அல்ல. கீழே உள்ள etiquette பகுதி, இந்த வேறுபாடு உங்கள் agent stack-ல் இது இருக்க வேண்டுமா என்பதை ஏன் தீர்மானிக்கிறது என்பதை விளக்குகிறது.

சிறிய VPS-களில் browser pool ஏன் தோல்வியடைகிறது

ஒவ்வொரு திறந்திருக்கும் browser tab-ம் தனித்தனி renderer process ஆகும்; இவை ஒவ்வொன்றும் தங்களுக்கென சொந்த DOM (document object model) மற்றும் JavaScript heap-ஐக் கொண்டுள்ளன. எனவே, memory பயன்பாடு என்பது ஒரு நாளில் எத்தனை பக்கங்கள் பார்க்கப்படுகின்றன என்பதைப் பொறுத்தல்ல, ஒரே நேரத்தில் எத்தனை பக்கங்கள் திறக்கப்பட்டுள்ளன என்பதைப் பொறுத்தே அமைகிறது. இந்த இரண்டு திட்டங்களும் அந்தச் செலவை அவற்றின் சொந்த 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 container-ன் அளவை 8 GB ஆகவும், அதன் Playwright container-ன் அளவை 4 GB ஆகவும் கட்டுப்படுத்துகிறது; இதற்கேற்ப swap வரம்புகளும் அமைக்கப்பட்டுள்ளன. Hound-ன் compose கோப்பு, Chromium-ஐ உள்ளடக்கிய ஒரு container-க்கு 3 GB-ஐ ஒதுக்குகிறது. இவை அந்தத் திட்டங்கள் தேர்ந்தெடுத்த உச்சவரம்புகள்; இவை அமைதியான நிலையில் அளவிடப்பட்டவை அல்ல, மாறாக வெளியிடப்பட்ட புள்ளிவிவரங்கள். மேலும், Redis, RabbitMQ, PostgreSQL மற்றும் FoundationDB ஆகியவற்றுக்கு Firecrawl எண்களுக்கு மேலதிகமாகத் தனிப்பட்ட memory தேவைப்படும்.

உங்களிடம் உள்ள RAM-ஐ விட அதிகமான உச்சவரம்பை அமைப்பதால் எந்தப் பயனும் இல்லை. கணினியில் memory தீர்ந்துவிட்டால், kernel-ன் out-of-memory killer ஒரு process-ஐ முடித்துவிடும். இதனால், application log-ல் எந்தப் பிழையும் பதிவாகாமல், ஒரு container docker compose ps-லிருந்து மறைந்துவிடும். விளக்க முடியாத எந்தவொரு restart-க்குப் பிறகும் dmesg -T | tail-ஐப் படிக்கவும். முழுமையான Firecrawl stack-க்கு 8 GB-ஐ பட்ஜெட்டாகக் கொள்ளவும், 4 GB-ஐ சோதனைக்கான குறைந்தபட்ச அளவாகக் கருதவும். ஒவ்வொரு service-க்கும் எண்களை அமைப்பது Docker Compose-ல் memory வரம்புகள் பகுதியில் விளக்கப்பட்டுள்ளது.

browser தொடர்பான மற்றொரு நுணுக்கம் பலரது மாலை நேரத்தை வீணாக்குகிறது. Docker ஒரு container-க்கு /dev/shm-ல் 64 MB shared memory-ஐ வழங்குகிறது. Chromium அதன் renderer buffers-ஐ அங்கு வைப்பதால், அதிகப்படியான தரவு கொண்ட பக்கங்களில் அது செயலிழக்கிறது (crashes). இரண்டு browser stack-களும் இதை அதிகரிக்கின்றன: Hound-ன் compose கோப்பில் shm_size: "1gb" உள்ளது. Playwright-ஐ அடிப்படையாகக் கொண்டு நீங்கள் உருவாக்கும் எந்தவொரு image-லும் அந்த வரியை நகலெடுத்துச் சேர்க்கவும்.

JavaScript அதிகம் பயன்படுத்தும் பக்கங்களில் பிரித்தெடுத்தல் தரம்

Static HTML, server-side rendering செய்யப்பட்ட வலைப்பதிவு, ஆவணப் பக்கம் அல்லது செய்தி கட்டுரை என எதுவாக இருந்தாலும், இவை அனைத்தும் கிட்டத்தட்ட ஒரே மாதிரியான markdown-ஐ வழங்குகின்றன; இதில் வேகமானதே வெற்றி பெறுகிறது. Client-side rendering செய்யப்படும் பக்கங்களில் தான் வேறுபாடு வெளிப்படுகிறது; அங்கு வழங்கப்படும் HTML ஒரு காலியான கூடு போல இருக்கும், பக்கம் ஏற்றப்பட்ட பிறகு JavaScript மூலமே உரை (text) வந்து சேரும்.

Draco படிப்படியாகத் தனது திறனை உயர்த்துகிறது. Tier 0 மற்றும் tier 1 ஆகியவை JavaScript இல்லாமலேயே HTML-ஐப் பகுப்பாய்வு செய்கின்றன. Tier 2, அந்தப் பக்கத்தின் சொந்த JavaScript-ஐ ஒரு in-process V8 isolate-க்குள் இயக்குகிறது. இது உலாவியின் (browser) சூழல் இல்லாத JavaScript engine ஆகும். README-ல் குறிப்பிட்டுள்ளபடி, அங்குள்ள பக்கக் குறியீடுகளுக்கு host capability bindings கிடையாது. இது பல single-page applications-ஐ, ஒரு உலாவியின் நினைவகத் தேவையில் ஒரு சிறு பகுதியிலேயே கையாள்கிறது. Draco ஒரு தடையைச் சந்திக்கும் போது, draco scrape ஆனது 3 என்ற குறியீட்டுடன் வெளியேறுகிறது, needs_browser. இதை scripts-ல் சரிபார்க்கவும், ஏனெனில் பூஜ்ஜிய வெளியேற்றக் குறியீட்டைக் கொண்ட ஒரு காலி கோப்பு, ஒரு முகவரின் (agent) சூழலை அமைதியாகப் பாதிக்கும் தோல்வியாகும்:

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

Firecrawl-ன் playwright-service ஒரு உண்மையான Chromium-ஐ இயக்குவதால், அது ஒரு உலாவி எதைக் காட்டுகிறதோ அதையே வழங்குகிறது. சுய-வழங்கி (self-hosted) உருவாக்கம் என்பது கிளவுட் தயாரிப்புக்கு இணையானது அல்ல: சுய-வழங்கி instances-க்கு Fire Engine-க்கான அணுகல் இல்லை என்று ஆவணங்கள் கூறுகின்றன. இதனால் கிளவுட் சேவையின் anti-blocking மற்றும் IP rotation வசதிகள் இதில் இல்லை, மேலும் /agent மற்றும் /browser endpoints-ம் ஆதரிக்கப்படுவதில்லை. Hound வேண்டுமென்றே இந்த இரண்டிற்கும் இடையில் செயல்படுகிறது. இது HTTP வழியாகத் தரவைப் பெற்று, ஒவ்வொரு கோரிக்கைக்கும் ஏற்பத் தனது திறனை உயர்த்துகிறது. அதன் warm browser ஒரு குறிப்பிட்ட கால செயலற்ற நிலைக்குப் பிறகு மூடப்படும், எனவே ஒரு அமைதியான கணினி அதன் அடிப்படை நினைவகப் பயன்பாட்டிலேயே இருக்கும்.

Draco-வை ஒரு குறிப்பிட்ட version-ல் நிறுவுதல்

README கோப்பில் ஒரு வரியில் நிறுவும் முறை கொடுக்கப்பட்டுள்ளது. அதை shell-க்கு அனுப்பும் முன் அது என்ன செய்கிறது என்பதைப் படியுங்கள்: அது $HOME/.draco/bin/draco-ல் நிறுவுகிறது, அது எப்போதும் latest release-ஐயே எடுக்கிறது, மேலும் அது எந்த signature அல்லது hash-ஐயும் சரிபார்ப்பதில்லை. ஒரு server-ல், version-ஐ pin செய்து, பதிவிறக்கத்தைச் சரிபார்க்கவும்.

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 வெளியிட்ட bytes-ம் ஒன்றாக இல்லை என்று அர்த்தம், எனவே அவற்றை நீக்கிவிட்டு மீண்டும் தொடங்கவும்.

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 பக்கத்தை markdown வடிவில் ஒரு நொடிக்கும் குறைவான நேரத்தில் அச்சிடும். find என்பது அலங்காரத்திற்காக அல்ல: archive அமைப்பு அந்த project-ன் பொது ஒப்பந்தத்தின் ஒரு பகுதி அல்ல, மேலும் அதிகாரப்பூர்வ 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-ஐப் படிக்கவும். பொதுவாக, Firecrawl-ன் default port-ம் 3002 என்பதால், வேறொரு process ஏற்கனவே அந்த port-ஐப் பயன்படுத்திக்கொண்டிருக்கலாம்; --port மூலம் ஏதேனும் ஒன்றை மாற்றலாம். Unit files பற்றிய கூடுதல் விவரங்களுக்கு: systemd service units and timers.

இப்போது உங்கள் agent பயன்படுத்தும் வழியில் fetch செய்யவும்:

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-ஐயும் கோர முடியும். இதனால் ஏற்படும் துஷ்பிரயோக புகார்கள் (abuse reports) அவர்களுக்குச் செல்லாது, உங்கள் service provider-க்குத்தான் வரும். Draco-வின் ஆவணப்படுத்தப்பட்ட serve flags-ல் API key வசதி இல்லை, எனவே network மட்டத்திலேயே பாதுகாப்பை உறுதி செய்ய வேண்டும். Agent ஒரே server-ல் இயங்கினால், default 127.0.0.1 bind-ஐ அப்படியே வைத்திருக்கவும். Agent வேறொரு இடத்தில் இருந்தால், இரண்டு முனைகளையும் ஒரு private tunnel-ல் இணைக்கவும். இதற்கு நீங்கள் சொந்தமாக நடத்தும் WireGuard VPN பொதுவாகப் பயன்படுத்தப்படுகிறது. அப்போது 0.0.0.0-க்கு பதிலாக tunnel address-ல் bind செய்யவும். அதன் பிறகு, பொது IP எதற்கும் பதிலளிக்கவில்லை என்பதை வேறொரு machine-லிருந்து உறுதிப்படுத்தவும். ufw firewall அடிப்படைகள் மற்றும் குறைந்தபட்ச அதிகாரமுள்ள user accounts ஆகிய இரண்டும் இதற்கான பாதுகாப்பை வழங்குகின்றன.

உங்கள் agent code மாறுமா? நடைமுறையில் API compatibility

Draco, Firecrawl v1 வழித்தடங்களான /v1/scrape, /v1/map, /v1/crawl, /v1/batch/scrape மற்றும் /v1/search ஆகியவற்றிற்குப் பதிலளிக்கிறது. அறியப்படாத புலங்கள் (fields) ஏற்றுக்கொள்ளப்பட்டு புறக்கணிக்கப்படும் என்று அதன் README குறிப்பிடுகிறது. ஏற்கனவே /v1/scrape-க்குத் தகவல்களை அனுப்பும் ஒரு agent-க்கு, புதிய base URL மட்டுமே தேவைப்படும், வேறு மாற்றம் தேவையில்லை. மறுபுறம் என்ன மாறியுள்ளது என்பதைக் கவனியுங்கள்: Firecrawl-ன் சொந்த self-hosting பக்கம் இப்போது /v2/crawl மூலம் சோதிக்கிறது. தற்போதைய SDK-கள் v2-ல் இயங்குகின்றன, எனவே Draco-வைச் சுட்டிக்காட்டும் v2 client, Draco வெளியிடாத ஒரு வழித்தடத்தைக் கேட்கும். agent code-ஐத் திருத்துவதற்கு முன் ஒவ்வொரு அழைப்பையும் curl மூலம் சோதிக்கவும். status code-ஐ விட JSON body-ஐப் படிக்கவும், ஏனெனில் இந்த implementations-க்கு இடையே புலங்களின் பெயர்களே மாறுபடுகின்றன.

Robots.txt, rate limits, மற்றும் கவனத்தில் கொள்ள வேண்டிய எல்லைகள்

Draco இயல்பாகவே robots.txt-ஐ வாசிக்கும், --ignore-robots அதை முடக்கும். Firecrawl-ம் அதே இயல்புநிலையைக் கொண்டுள்ளது. இரண்டையும் மாற்ற வேண்டாம். பிறகு, உங்கள் வேகத்தை நீங்களே நிர்ணயித்துக் கொள்ளுங்கள்: --delay கோரிக்கைகளுக்கு இடையே மில்லி விநாடிகளை அமைக்கும், --max-concurrency இணையாக இயங்கும் பணிகளைக் கட்டுப்படுத்தும்; daemon இயல்புநிலை 8 ஆக உள்ளது. பகிரப்பட்ட VPS இணைப்பில் 2 முதல் 4 வரை அமைப்பது சிறந்தது, இது ஒட்டுமொத்த வேகத்தை அவ்வளவாகக் குறைக்காது. ஏனெனில், ஒரு தளம் உங்களை rate limit செய்யத் தொடங்கினால், நீங்கள் சேமித்த concurrency-ஐ விட அதிக நேரம் வீணாகும். நீங்கள் பெறுவதை cache செய்யுங்கள், அப்போதுதான் இரண்டாவது முறை agent இயங்கும்போது மூலத் தளத்திற்கு எந்தச் சுமையுமில்லை. AI agent செலவுகளைக் கட்டுப்படுத்துதல் என்பதில் இதுவே மிகக் குறைந்த செலவு கொண்ட அம்சமாகும்.

Challenge walls என்பது தனிப்பட்ட விஷயம், இதற்காகவே Trawl உருவாக்கப்பட்டுள்ளது: Cloudflare Turnstile, reCAPTCHA, hCaptcha மற்றும் GeeTest. ஒரு challenge wall என்பது தானியங்கி traffic-ஐ ஒரு தளம் வெளிப்படையாக மறுப்பதாகும். இதைத் தவிர்த்துச் செயல்படுவது அந்தத் தளத்தின் பயன்பாட்டு விதிகளுக்கு எதிரானது, சில இடங்களில் சட்டவிரோதமானதும்கூட. எனவே, இந்த வழிகாட்டி fetching infrastructure-உடன் நின்றுவிடுகிறது. ஒரு wall-ஐத் தாண்டும் அதே நுட்பங்களைத்தான் தள உரிமையாளர்கள் கண்காணித்துத் தடுக்கிறார்கள், இது உங்கள் pipeline-ஐ பலவீனமாகவும், நாகரிகமற்றதாகவும் மாற்றும். ஒரு தளம் உங்களுக்கு மிக முக்கியம் என்றால், அதன் RSS feed, public API, அல்லது bulk export வசதிகளைத் தேடுங்கள். இவை ஒவ்வொன்றும் குறைந்த செலவில் இயங்கக்கூடியவை, மேலும் wall-ல் மாற்றம் ஏற்படும்போது இவை பாதிக்கப்படாது.

MCP மூலம் ஒரு agent-உடன் இணைத்தல்

MCP (model context protocol) என்பது ஒரு agent கருவியைப் (tool) பயன்படுத்தும் இடைமுகமாகும். Draco, stdio வழியாக அதே binary-க்குள் ஒரு MCP server-ஐக் கொண்டுள்ளது:

{ "mcpServers": { "draco": { "command": "draco", "args": ["mcp"] } } }

இந்தக் கருவிகள் agent-க்கு draco_scrape, draco_search மற்றும் draco_interact_* தொகுப்பாகத் தெரியும். Stdio என்பது agent process மற்றும் binary ஒரே machine-ல் இருக்கும்போது மட்டுமே செயல்படும், ஏனெனில் இதன் transport அந்த process-ன் standard input ஆகும். வேறொரு host-ல் உள்ள agent-க்கு, Hound அதற்குப் பதிலாக HTTP வழியாக MCP-ஐ வழங்குகிறது: hound --http --host 127.0.0.1 --port 8765 என்பது http://127.0.0.1:8765/mcp-ல் ஒரு endpoint-ஐ வெளியிடுகிறது, அதை நீங்கள் tunnel வழியாக அணுகலாம். Transport தேர்வுகள் மற்றும் எதை வெளிப்படுத்த வேண்டும் என்பது VPS-ல் MCP server-களை இயக்குதல் பகுதியில் உள்ளது.

தேடல் மூலம் இணைகளைப் பெறுதல். Fetch மட்டும் செய்யக்கூடிய ஒரு agent, நீங்கள் URL-களை வழங்கும் வரை காத்திருக்கும். சுயமாக host செய்யப்பட்ட SearXNG search instance-ஐச் சேர்த்தால், அதுவே URL-களைக் கண்டறியும்; இது SearXNG-ல் கட்டமைக்கப்பட்ட browser search skill-ன் அதே அமைப்பைக் கொண்டது. Daemon இயங்கத் தொடங்கியதும், நீங்கள் இயக்கும் சுயமாக host செய்யப்பட்ட AI agent-கள் அனைத்திற்கும் இது ஒரு பகிரப்பட்ட சேவையாக இருக்கும்.

FAQ

AI agent-க்காக பக்கங்களை எடுக்க headless browser தேவையா?

பெரும்பாலான பக்கங்களுக்குத் தேவையில்லை. Server-ல் render செய்யப்படும் ஆவணங்கள், வலைப்பதிவுகள் மற்றும் செய்திக் கட்டுரைகள், சாதாரண HTTP fetch மற்றும் HTML-to-markdown மாற்றத்தின் மூலமே முழுமையாகக் கிடைத்துவிடும். Draco-வின் கீழ்நிலை அடுக்குகளில், திட்டத்தின் தரவுகளின்படி, ஒரு பக்கத்திற்கு சுமார் 300 ms நேரத்தில், browser இல்லாமலேயே இது நடைபெறுகிறது. Client-ல் render செய்யப்படும் applications-க்கு மட்டுமே browser தேவைப்படுகிறது, ஏனெனில் அங்கு கிடைக்கும் HTML வெறும் காலியான சட்டமாகவே இருக்கும். Draco-வின் V8 isolate, browser process இல்லாமலேயே அந்த இடைப்பட்ட தேவைகளை நிறைவு செய்கிறது. அவ்வாறு செய்ய முடியாதபோது, அது needs_browser என்ற code 3-உடன் வெளியேறுகிறது.

VPS-ல் self-hosted Firecrawl-க்கு எவ்வளவு RAM தேவை?

அதன் compose file, api container-க்கு 8 GB மற்றும் Playwright container-க்கு 4 GB என்ற உச்சவரம்பை நிர்ணயிக்கிறது. அதே stack-ல் Redis, RabbitMQ, PostgreSQL மற்றும் FoundationDB ஆகியவையும் தொடங்குகின்றன. எனவே 8 GB RAM-ஐத் திட்டமிடுங்கள். 2 GB கொண்ட server-ல், சுமை அதிகரிக்கும்போது kernel-ன் out-of-memory killer, container-களை நீக்கிவிடும். இதன் முதல் அறிகுறி, docker compose ps-ல் container மீண்டும் தொடங்குவதுதான்; ஆனால் application log-ல் பயனுள்ள தகவல்கள் எதுவும் இருக்காது. எனவே dmesg -T | tail மூலம் இதை உறுதிப்படுத்தவும்.

Draco, Firecrawl API-க்கு மாற்றாக அமையுமா?

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 இதில் இல்லை. உங்கள் agent செய்யும் ஒவ்வொரு அழைப்பையும் முதலில் curl மூலம் சரிபார்க்கவும்.

Scraper-ஐ self-host செய்வது robots.txt-ஐப் புறக்கணிக்கலாம் என்று அர்த்தமா?

இல்லை. குறியீடு (code) எங்கு இயங்கினாலும், ஒரு தளம் எதை வெளியிட்டது அல்லது அதன் விதிகள் எதை அனுமதிக்கின்றன என்பது மாறாது. Draco மற்றும் Firecrawl ஆகிய இரண்டுமே இயல்பாகவே robots.txt-ஐ மதிக்கின்றன. நீங்கள் சொந்தமாக வைத்திருக்கும் அல்லது crawl செய்ய எழுத்துப்பூர்வ அனுமதி பெற்ற தளங்களுக்கு மட்டும் override flag-ஐப் பயன்படுத்தலாம். Rate limits-கள் எப்படியும் கடைசியில் அமல்படுத்தப்படும், எனவே குறைந்த concurrency கொண்ட ஒரு கனிவான --delay, உங்கள் IP address-ஐத் தொடர்ந்து செயல்பட வைக்கும். ஒரு challenge wall-ஐத் தகர்ப்பதன் மூலம் மட்டுமே செயல்படும் stack, எந்த எச்சரிக்கையும் இன்றி செயலிழந்துவிடும்.