ทางเลือก Self-hosted Firecrawl สำหรับรันบน VPS

สิ่งที่ทางเลือกสำหรับ self-hosted Firecrawl ต้องทำได้

ทางเลือกสำหรับการทำ self-hosted Firecrawl มีหน้าที่หลักเพียงอย่างเดียวคือ รับ URL เข้ามาแล้วส่งคืนเนื้อหาหน้าเว็บในรูปแบบ markdown ที่สะอาดตาเพื่อให้ agent อ่านได้ บริการ API แบบ hosted จะคิดค่าใช้จ่ายต่อหน้า ซึ่งทำให้ค่าใช้จ่ายเพิ่มขึ้นตามความต้องการของ agent ในขณะที่ VPS ที่คุณจ่ายเงินใช้งานอยู่แล้วสามารถทำงานเดียวกันนี้ได้ โครงการต่างๆ จะมีความแตกต่างกันในประเด็นสำคัญคือ จำเป็นต้องรัน headless browser (เอนจินเบราว์เซอร์จริงที่ทำงานโดยไม่มีหน้าต่างแสดงผล) บนเครื่องของคุณหรือไม่

คำตอบในส่วนนี้จะเป็นตัวกำหนดปริมาณการใช้หน่วยความจำ, ต้นทุนต่อหน้า และโอกาสที่หน้าเว็บจะถูกส่งกลับมาเป็นค่าว่าง คู่มือนี้จะเปรียบเทียบระหว่าง Draco, Hound และตัว Firecrawl เวอร์ชัน self-hosted พร้อมทั้งแนะนำวิธีการติดตั้งตัวที่เบาที่สุดในเวอร์ชันที่กำหนดไว้ และเชื่อมต่อเข้ากับ agent ผ่านทาง MCP (model context protocol)

โครงการทั้งสี่และรายละเอียดของแต่ละโครงการ

Draco เป็นไฟล์ binary เดียวที่เขียนด้วยภาษา Rust ภายใต้สัญญาอนุญาต MIT หรือ Apache-2.0 โดยรุ่น v0.20.5 ได้รับการเผยแพร่เมื่อวันที่ 16 กรกฎาคม 2026 draco scrape <url> จะพิมพ์ markdown ออกทาง stdout ส่วน draco serve จะรัน daemon ที่คอยตอบรับคำขอที่ 127.0.0.1:3002 ซึ่งเป็นพอร์ตเดียวกับที่ Firecrawl ใช้งาน โครงการนี้ไม่มี container image และไม่เรียกใช้งานเบราว์เซอร์

Firecrawl self-hosted คือ engine ที่อยู่เบื้องหลังผลิตภัณฑ์แบบ hosted ภายใต้สัญญาอนุญาต AGPL-3.0 โดย docker-compose.yaml ของโครงการนี้กำหนดบริการไว้เจ็ดรายการ ได้แก่ playwright-service, api, redis, rabbitmq, nuq-postgres, foundationdb และ foundationdb-init คุณจะได้รับคิวการ crawl จริง แต่ต้องแลกกับการรันระบบแบบกระจายขนาดเล็ก

Hound อยู่ใน repository master-fetch และถูกส่งไปยัง PyPI ในชื่อ hound-mcp ภายใต้สัญญาอนุญาต MIT รุ่น 13.0.1 ณ วันที่ 3 สิงหาคม 2026 โดยต้องการ Python 3.11 หรือใหม่กว่า โครงการนี้เป็น MCP server เป็นหลักและเป็นตัวดึงข้อมูลเป็นรอง โดยจะพยายามดึงข้อมูลด้วย HTTP ปกติก่อน และจะเริ่มใช้งานเบราว์เซอร์ Patchright ก็ต่อเมื่อการดึงข้อมูลปกติถูกบล็อกเท่านั้น

Trawl อยู่ในรายการนี้เพราะผู้คนมักพบเจอขณะค้นหาโครงการอื่น ๆ และมันทำหน้าที่ต่างออกไป โดยทำหน้าที่แก้โจทย์ JavaScript และ CAPTCHA ด้วย Firefox ที่มีการปรับแต่ง fingerprint เพื่อใช้ทดแทน FlareSolverr ใน stack สื่อแบบ *arr มันไม่ใช่เครื่องมือดึงข้อมูล markdown ส่วนเนื้อหาเรื่องมารยาทด้านล่างจะอธิบายว่าเหตุใดความแตกต่างนี้จึงเป็นตัวตัดสินว่ามันควรอยู่ใน agent stack ของคุณหรือไม่

เหตุผลที่ Browser Pool เป็นสาเหตุให้ VPS ขนาดเล็กทำงานล้มเหลว

Browser แต่ละแท็บที่เปิดอยู่คือกระบวนการ Renderer แยกต่างหาก ซึ่งมี DOM (Document Object Model) และ JavaScript heap ของตัวเอง ดังนั้นการใช้หน่วยความจำจึงแปรผันตามจำนวนหน้าที่เปิดใช้งานพร้อมกัน ไม่ใช่จำนวนหน้าที่เรียกดูต่อวัน โครงการเหล่านี้สองโครงการได้ระบุต้นทุนดังกล่าวไว้ในไฟล์ compose ของตนเอง

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

ไฟล์ compose ของ Firecrawl จำกัดหน่วยความจำของคอนเทนเนอร์ api ไว้ที่ 8 GB และคอนเทนเนอร์ Playwright ไว้ที่ 4 GB พร้อมกำหนดค่า swap limit ที่สอดคล้องกัน ส่วนไฟล์ compose ของ Hound กำหนดไว้ที่ 3 GB สำหรับคอนเทนเนอร์เดียวที่รวม Chromium มาด้วย ค่าเหล่านี้เป็นเพดานที่โครงการกำหนดขึ้น ซึ่งเป็นตัวเลขที่ประกาศไว้มากกว่าจะเป็นการวัดผลจากระบบที่ไม่มีภาระงาน นอกจากนี้ Redis, RabbitMQ, PostgreSQL และ FoundationDB ยังคงต้องการส่วนแบ่งหน่วยความจำเพิ่มเติมจากตัวเลขของ Firecrawl อีกด้วย

การตั้งค่าเพดานที่สูงกว่า RAM ที่คุณมีอยู่จริงนั้นไม่มีผลใดๆ เมื่อเซิร์ฟเวอร์หน่วยความจำเต็ม Kernel จะใช้กลไก out-of-memory killer เพื่อยุติกระบวนการ ส่งผลให้คอนเทนเนอร์หายไปจาก docker compose ps โดยไม่มีข้อความแสดงข้อผิดพลาดใน log ของแอปพลิเคชัน ให้ตรวจสอบ dmesg -T | tail หลังจากมีการรีสตาร์ทที่คุณไม่สามารถอธิบายสาเหตุได้ ควรจัดสรรหน่วยความจำไว้ที่ 8 GB สำหรับการรัน Firecrawl แบบเต็มรูปแบบ และถือว่า 4 GB เป็นค่าต่ำสุดสำหรับเครื่องทดสอบ การตั้งค่าตัวเลขสำหรับแต่ละบริการมีอธิบายไว้ใน การจำกัดหน่วยความจำใน Docker Compose

รายละเอียดเกี่ยวกับ Browser อีกประการหนึ่งที่ทำให้ผู้ใช้เสียเวลาไปหนึ่งเย็นคือ Docker จะจัดสรรหน่วยความจำร่วม (shared memory) ให้คอนเทนเนอร์เพียง 64 MB ที่ /dev/shm ในขณะที่ Chromium ใช้พื้นที่ดังกล่าวสำหรับเก็บ renderer buffers ทำให้เกิดการ crash เมื่อเปิดหน้าเว็บที่มีเนื้อหาหนัก ทั้งสอง stack ของ browser จึงต้องเพิ่มค่านี้ โดยไฟล์ compose ของ Hound ได้ระบุไว้ที่ shm_size: "1gb" ให้คัดลอกบรรทัดดังกล่าวไปใส่ใน image ใดก็ตามที่คุณสร้างขึ้นโดยใช้ Playwright

คุณภาพการดึงข้อมูลบนหน้าเว็บที่ใช้ JavaScript จำนวนมาก

สำหรับหน้า HTML แบบคงที่ บล็อกที่เรนเดอร์จากฝั่งเซิร์ฟเวอร์ หน้าเอกสาร หรือบทความข่าว ข้อมูลทั้งหมดนี้จะส่งกลับเป็น Markdown ที่แทบจะเหมือนกัน และวิธีที่เร็วที่สุดจะเป็นผู้ชนะ ความแตกต่างจะปรากฏชัดในหน้าเว็บที่เรนเดอร์จากฝั่งไคลเอนต์ ซึ่ง HTML ที่ได้รับมาเป็นเพียงโครงเปล่า และข้อความจะถูกส่งมาผ่าน JavaScript หลังจากโหลดหน้าเว็บเสร็จสิ้น

Draco มีการยกระดับการทำงานเป็นลำดับชั้น (tiers) โดย Tier 0 และ Tier 1 จะทำการแยกวิเคราะห์ (parse) HTML โดยไม่ใช้ JavaScript เลย ส่วน Tier 2 จะรัน JavaScript ของหน้าเว็บนั้นภายใน V8 isolate ที่ทำงานอยู่ภายในกระบวนการ (in-process) ซึ่งเป็นเอนจิน JavaScript ที่ไม่มีเบราว์เซอร์ครอบอยู่ และ README ระบุว่าโค้ดของหน้าเว็บจะไม่ได้รับสิทธิ์ในการเข้าถึงความสามารถของโฮสต์ในส่วนนี้ วิธีนี้ครอบคลุมแอปพลิเคชันหน้าเดียว (SPA) จำนวนมากโดยใช้หน่วยความจำเพียงเศษเสี้ยวของเบราว์เซอร์ เมื่อ Draco พบอุปสรรคที่ไม่สามารถผ่านไปได้ draco scrape จะยุติการทำงานด้วยรหัส 3 หรือ needs_browser ให้ตรวจสอบสถานะนี้ในสคริปต์ เพราะไฟล์ว่างเปล่าที่ส่งรหัสสถานะเป็นศูนย์ถือเป็นความล้มเหลวที่ส่งผลเสียต่อบริบทของเอเจนต์อย่างเงียบเชียบ:

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

playwright-service ของ Firecrawl ขับเคลื่อนด้วย Chromium จริง จึงเรนเดอร์ผลลัพธ์ได้เหมือนกับที่เบราว์เซอร์แสดงผล อย่างไรก็ตาม รุ่นที่โฮสต์เอง (self-hosted) ยังไม่ใช่ผลิตภัณฑ์แบบคลาวด์ โดยเอกสารระบุว่าอินสแตนซ์ที่โฮสต์เองไม่มีสิทธิ์เข้าถึง Fire Engine ดังนั้นฟีเจอร์ป้องกันการบล็อกและการหมุนเวียน IP ของบริการคลาวด์จึงไม่มีให้ใช้งาน และ endpoint /agent กับ /browser ก็ไม่ได้รับการสนับสนุน ส่วน Hound ถูกออกแบบมาให้อยู่ตรงกลางโดยเจตนา มันดึงข้อมูลผ่าน HTTP และยกระดับการทำงานตามคำขอ โดยเบราว์เซอร์ที่เตรียมพร้อมไว้จะปิดตัวลงหลังจากไม่มีการใช้งานตามระยะเวลาที่กำหนด ดังนั้นเครื่องที่ไม่มีการใช้งานจะยังคงใช้ทรัพยากรใกล้เคียงกับค่าพื้นฐาน

การติดตั้ง Draco ด้วยเวอร์ชันที่ระบุไว้ (Pinned version)

README ได้ระบุวิธีการติดตั้งแบบบรรทัดเดียวไว้ โปรดอ่านสิ่งที่คำสั่งนั้นทำก่อนที่จะส่งต่อไปยัง shell: คำสั่งดังกล่าวจะติดตั้งลงใน $HOME/.draco/bin/draco, ดึงเวอร์ชัน latest มาเสมอ และไม่มีการตรวจสอบลายเซ็นหรือค่า 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

คำสั่งสุดท้ายจะแสดงหน้าตัวอย่างในรูปแบบ markdown ภายในเวลาไม่ถึงหนึ่งวินาที ส่วน find ไม่ใช่แค่การตกแต่ง: โครงสร้างของ archive ไม่ใช่ส่วนหนึ่งของสัญญาการใช้งานสาธารณะของโครงการ และตัวติดตั้งอย่างเป็นทางการก็ค้นหา binary ด้วยวิธีเดียวกันนี้

ให้รัน 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

/health จะตอบกลับทันทีที่ daemon เริ่มฟังพอร์ต หากขึ้น Connection refused หมายความว่า daemon ยังไม่ทำงาน ให้ตรวจสอบ journalctl -u draco -n 50 สาเหตุที่พบบ่อยคือมีกระบวนการอื่นใช้งานพอร์ต 3002 อยู่แล้ว เนื่องจากเป็นพอร์ตเริ่มต้นของ Firecrawl ด้วยเช่นกัน คุณสามารถใช้ --port เพื่อเปลี่ยนพอร์ตของบริการใดบริการหนึ่งได้ ข้อมูลเพิ่มเติมเกี่ยวกับ unit files: systemd service units and timers

ตอนนี้ให้ดึงข้อมูลในรูปแบบที่ agent ของคุณจะใช้งาน:

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 ที่ไม่มีการตรวจสอบสิทธิ์จะกลายเป็น open proxy ทันที ใครก็ตามที่เข้าถึงพอร์ตดังกล่าวได้จะสามารถสั่งให้เซิร์ฟเวอร์ของคุณร้องขอ URL ใดๆ ภายใต้ IP ของคุณ ซึ่งรายงานการละเมิดจะถูกส่งไปยังผู้ให้บริการของคุณไม่ใช่ผู้กระทำผิด เอกสารของ Draco ระบุว่า serve flags ไม่มี API key ดังนั้นการป้องกันจึงต้องทำที่ระดับเครือข่าย ให้คงค่า 127.0.0.1 bind ตามค่าเริ่มต้นไว้เมื่อ agent ทำงานบนเครื่องเดียวกัน หาก agent อยู่ที่อื่น ให้เชื่อมต่อทั้งสองฝั่งผ่าน private tunnel โดยทั่วไปมักใช้ WireGuard VPN ที่คุณโฮสต์เอง และให้ bind ไปที่ tunnel address แทนที่จะเป็น 0.0.0.0 จากนั้นให้ตรวจสอบจากเครื่องอื่นว่า IP สาธารณะไม่ตอบสนองต่อการเชื่อมต่อใดๆ พื้นฐาน ufw firewall และ บัญชีผู้ใช้ที่มีสิทธิ์น้อยที่สุด ครอบคลุมการป้องกันทั้งสองส่วนนี้

โค้ดเอเจนต์ของคุณจะมีการเปลี่ยนแปลงหรือไม่? ความเข้ากันได้ของ API ในทางปฏิบัติ

Draco ตอบสนองต่อเส้นทางของ Firecrawl v1 ได้แก่ /v1/scrape, /v1/map, /v1/crawl, /v1/batch/scrape และ /v1/search โดยใน README ระบุว่าฟิลด์ที่ไม่รู้จักจะถูกยอมรับและละเว้น เอเจนต์ที่ส่งข้อมูลไปยัง /v1/scrape อยู่แล้วจำเป็นต้องเปลี่ยนเพียงแค่ base URL เท่านั้น ให้ตรวจสอบสิ่งที่เปลี่ยนแปลงในฝั่งตรงข้าม: หน้าการ self-host ของ Firecrawl เองในขณะนี้ทดสอบด้วย /v2/crawl และ SDK ปัจจุบันรองรับ v2 ดังนั้นไคลเอนต์ v2 ที่ชี้ไปยัง Draco จะเรียกใช้เส้นทางที่ Draco ไม่ได้เปิดให้บริการ ให้ทดสอบการเรียกใช้งานแต่ละรายการด้วย curl ก่อนที่คุณจะแก้ไขโค้ดเอเจนต์ และให้อ่านเนื้อหา JSON แทนการดู status code เนื่องจากชื่อฟิลด์คือจุดที่การใช้งานเหล่านี้มีความแตกต่างกัน

Robots.txt, rate limits และขอบเขตที่ควรเว้นระยะ

Draco จะอ่าน robots.txt โดยค่าเริ่มต้น และ --ignore-robots จะปิดการทำงานดังกล่าว ให้คงค่าเริ่มต้นของทั้งสองส่วนไว้ จากนั้นจึงกำหนดความเร็วในการทำงานด้วยตนเอง: --delay ใช้กำหนดระยะเวลาเป็นมิลลิวินาทีระหว่างการร้องขอแต่ละครั้ง และ --max-concurrency ใช้จำกัดจำนวนงานที่ทำขนานกัน โดยค่าเริ่มต้นของ daemon คือ 8 การตั้งค่าไว้ที่ 2 ถึง 4 จะเป็นมิตรต่อการเชื่อมต่อบน VPS ที่ใช้งานร่วมกันมากกว่า และมักจะไม่ช้าไปกว่าเดิม เพราะการที่เว็บไซต์เริ่มจำกัดอัตราการเข้าถึง (rate limiting) ของคุณจะทำให้เสียเวลามากกว่าการลดจำนวนงานขนานลง ให้ทำแคชข้อมูลที่ดึงมา เพื่อให้การรัน agent ในรอบถัดไปไม่ส่งผลกระทบต่อแหล่งข้อมูลต้นทาง ซึ่งนี่ยังเป็นรายการค่าใช้จ่ายที่ถูกที่สุดใน การควบคุมค่าใช้จ่ายสำหรับ AI agent

กำแพงป้องกัน (challenge walls) เป็นอีกเรื่องหนึ่ง และ Trawl ถูกสร้างมาเพื่อจัดการกับสิ่งนี้โดยเฉพาะ ไม่ว่าจะเป็น Cloudflare Turnstile, reCAPTCHA, hCaptcha หรือ GeeTest กำแพงป้องกันคือการที่เว็บไซต์ปฏิเสธทราฟฟิกอัตโนมัติอย่างชัดเจน การพยายามเลี่ยงกำแพงเหล่านี้ถือเป็นการละเมิดข้อกำหนดการใช้งานของเว็บไซต์ และในบางพื้นที่อาจผิดกฎหมาย ดังนั้นคู่มือนี้จึงครอบคลุมเพียงแค่โครงสร้างพื้นฐานในการดึงข้อมูลเท่านั้น เทคนิคที่ใช้ผ่านกำแพงป้องกันมักเป็นสิ่งที่เจ้าของเว็บไซต์คอยเฝ้าระวังและบล็อก ซึ่งจะทำให้ pipeline ใดก็ตามที่สร้างขึ้นด้วยวิธีนี้มีความเปราะบางและเป็นการเสียมารยาท หากแหล่งข้อมูลนั้นมีความสำคัญมาก ให้มองหา RSS feed, public API หรือการส่งออกข้อมูลแบบ bulk แทน วิธีเหล่านี้มีต้นทุนการรันที่ต่ำกว่าและจะไม่พังเมื่อมีการเปลี่ยนแปลงกำแพงป้องกันในอนาคต

เชื่อมต่อเข้ากับเอเจนต์ผ่าน MCP

MCP (model context protocol) คืออินเทอร์เฟซที่เอเจนต์ใช้สำหรับเรียกใช้เครื่องมือ Draco มี MCP server รวมอยู่ใน binary เดียวกันโดยสื่อสารผ่าน stdio:

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

จากนั้นเครื่องมือจะปรากฏแก่เอเจนต์ในรูปแบบของ draco_scrape, draco_search และชุด draco_interact_* การสื่อสารผ่าน stdio จะทำงานได้ก็ต่อเมื่อกระบวนการของเอเจนต์และ binary อยู่บนเครื่องเดียวกันเท่านั้น เนื่องจากช่องทางการรับส่งข้อมูลคือ standard input ของกระบวนการนั้น สำหรับเอเจนต์ที่อยู่บนโฮสต์อื่น Hound จะให้บริการ MCP ผ่าน HTTP แทน โดย hound --http --host 127.0.0.1 --port 8765 จะประกาศ endpoint ไว้ที่ http://127.0.0.1:8765/mcp ซึ่งคุณสามารถเข้าถึงได้ผ่านอุโมงค์เชื่อมต่อ (tunnel) รายละเอียดเกี่ยวกับการเลือกช่องทางการรับส่งข้อมูลและสิ่งที่ควรเปิดเผยอยู่ใน การรัน MCP server บน VPS

การดึงข้อมูลคู่ลำดับด้วยการค้นหา เอเจนต์ที่ทำได้เพียงดึงข้อมูลจะต้องรอให้คุณระบุ URL ให้ เพิ่ม อินสแตนซ์ SearXNG สำหรับการค้นหาแบบ self-hosted เพื่อให้เอเจนต์สามารถค้นหาข้อมูลได้ด้วยตนเอง ซึ่งมีรูปแบบเดียวกับ ทักษะการค้นหาผ่านเบราว์เซอร์ที่สร้างบน SearXNG เมื่อ daemon เริ่มทำงานแล้ว มันจะกลายเป็นบริการที่ใช้ร่วมกันสำหรับ เอเจนต์ AI แบบ self-hosted ตัวใดก็ตามที่คุณใช้งานอยู่

FAQ

ฉันจำเป็นต้องใช้ headless browser เพื่อดึงหน้าเว็บสำหรับ AI agent หรือไม่

ไม่จำเป็นสำหรับหน้าเว็บส่วนใหญ่ เอกสารประกอบ บล็อก และบทความข่าวที่ render จากฝั่งเซิร์ฟเวอร์จะส่งข้อมูลกลับมาครบถ้วนผ่านการดึงข้อมูล HTTP ปกติแล้วแปลง HTML เป็น markdown ซึ่งเป็นสิ่งที่ Draco ทำในระดับเริ่มต้นด้วยความเร็วประมาณ 300 ms ต่อหน้าโดยไม่ต้องใช้เบราว์เซอร์ตามข้อมูลของโครงการ การใช้เบราว์เซอร์จะสิ้นเปลืองหน่วยความจำกับแอปพลิเคชันที่ render ฝั่งไคลเอนต์ซึ่ง HTML ที่ได้รับมาเป็นเพียงโครงเปล่า V8 isolate ของ Draco ครอบคลุมการทำงานส่วนใหญ่โดยไม่ต้องมีกระบวนการเบราว์เซอร์ และจะจบการทำงานด้วยรหัส 3, needs_browser เมื่อไม่สามารถดำเนินการได้

การ self-host Firecrawl บน VPS ต้องใช้ RAM เท่าไร

ไฟล์ compose ของโครงการกำหนดเพดานหน่วยความจำไว้ที่ 8 GB สำหรับคอนเทนเนอร์ api และ 4 GB สำหรับคอนเทนเนอร์ Playwright นอกจากนี้ stack เดียวกันยังต้องรัน Redis, RabbitMQ, PostgreSQL และ FoundationDB ด้วย ควรวางแผนใช้ RAM อย่างน้อย 8 GB หากใช้เครื่องขนาด 2 GB ตัว kernel out-of-memory killer จะสั่งปิดคอนเทนเนอร์เมื่อมีโหลดสูง สัญญาณแรกที่พบคือคอนเทนเนอร์รีสตาร์ทใน docker compose ps โดยไม่มีข้อมูลที่เป็นประโยชน์ใน log ของแอปพลิเคชัน ดังนั้นให้ตรวจสอบด้วย dmesg -T | tail

Draco สามารถใช้แทน Firecrawl API ได้ทันทีเลยหรือไม่

สำหรับ endpoint v1 นั้นใกล้เคียงกันมาก โดยรองรับ /v1/scrape, /v1/map, /v1/crawl, /v1/batch/scrape และ /v1/search อีกทั้งยังเพิกเฉยต่อฟิลด์ใน request ที่ไม่รู้จัก ดังนั้นไคลเอนต์ที่เขียนขึ้นสำหรับ Firecrawl v1 มักต้องการเพียงการเปลี่ยน base URL ใหม่เท่านั้น อย่างไรก็ตาม Draco ไม่ใช่ผลิตภัณฑ์แบบ hosted จึงไม่มี managed proxy pool อยู่เบื้องหลัง และ route v2 ใหม่ของ Firecrawl ก็ไม่ได้รวมอยู่ในส่วนนี้ ให้ตรวจสอบการเรียกใช้งานแต่ละครั้งของ agent ด้วย curl ก่อนเสมอ

การ self-host เครื่องมือ scraper หมายความว่าฉันสามารถเพิกเฉยต่อ robots.txt ได้หรือไม่

ไม่สามารถทำได้ สถานที่ที่โค้ดทำงานไม่ได้เปลี่ยนแปลงสิ่งที่เว็บไซต์เผยแพร่หรือสิ่งที่ข้อกำหนดอนุญาต ทั้ง Draco และ Firecrawl เคารพ robots.txt เป็นค่าเริ่มต้น และมี flag สำหรับ override ไว้ใช้สำหรับเว็บไซต์ที่คุณเป็นเจ้าของหรือได้รับอนุญาตเป็นลายลักษณ์อักษรให้ crawl ได้ ทั้งนี้การจำกัดอัตราการเข้าถึง (rate limit) จะถูกบังคับจากฝั่งปลายทางอยู่ดี ดังนั้นการตั้งค่า --delay อย่างสุภาพด้วย concurrency ต่ำจะช่วยให้ IP address ของคุณใช้งานได้ต่อเนื่อง stack ใดที่ทำงานได้โดยการพยายามเอาชนะ challenge wall มักจะเป็น stack ที่หยุดทำงานโดยไม่มีการแจ้งเตือนล่วงหน้า