Alternatif Firecrawl Self-Hosted Terbaik untuk VPS

Keperluan alternatif Firecrawl yang dihoskan sendiri

Alternatif Firecrawl yang dihoskan sendiri mempunyai satu tugas: mengambil URL dan mengembalikan halaman tersebut sebagai markdown bersih yang boleh dibaca oleh ejen. API yang dihoskan mengenakan caj bagi setiap halaman, jadi bil akan meningkat mengikut tahap keingintahuan ejen anda, sedangkan VPS yang anda sudah bayar boleh melakukan kerja yang sama. Projek-projek ini terbahagi kepada satu persoalan: adakah pelayar tanpa kepala (enjin pelayar sebenar yang berjalan tanpa tetingkap) perlu dimulakan pada pelayan anda?

Jawapan tersebut menentukan penggunaan memori, kos setiap halaman, dan halaman mana yang akan kembali kosong. Panduan ini membandingkan Draco, Hound, dan keluaran Firecrawl yang dihoskan sendiri, memasang versi yang paling ringan pada versi yang ditetapkan, serta menyambungkannya kepada ejen melalui MCP (model context protocol).

Empat projek tersebut, dan fungsi sebenar setiap satunya

Draco ialah satu binari yang ditulis dalam Rust, dilesenkan di bawah MIT atau Apache-2.0. Keluaran v0.20.5 telah diterbitkan pada 16 Julai 2026. draco scrape <url> mencetak markdown ke stdout. draco serve menjalankan daemon yang menjawab pada 127.0.0.1:3002, port yang digunakan oleh Firecrawl. Ia tidak menghantar imej kontena dan tidak memulakan pelayar.

Firecrawl self-hosted ialah enjin di sebalik produk yang dihoskan, di bawah AGPL-3.0. docker-compose.yaml miliknya mentakrifkan tujuh servis: playwright-service, api, redis, rabbitmq, nuq-postgres, foundationdb dan foundationdb-init. Anda mendapat baris gilir crawl yang sebenar, dengan kos menjalankan sistem teragih yang kecil.

Hound berada dalam repositori master-fetch dan dihantar ke PyPI sebagai hound-mcp, dilesenkan di bawah MIT, versi 13.0.1 setakat 3 Ogos 2026. Ia memerlukan Python 3.11 atau lebih baharu. Ia merupakan pelayan MCP terlebih dahulu dan alat pengambil (fetcher) kemudian: ia mencuba HTTP biasa, dan hanya memulakan pelayar Patchright apabila pengambilan biasa disekat.

Trawl disertakan di sini kerana pengguna sering menemuinya semasa mencari projek lain, dan ia melakukan tugas yang berbeza. Ia menyelesaikan cabaran JavaScript dan CAPTCHA dengan Firefox yang dipatch dengan fingerprint, sebagai pengganti kepada FlareSolverr dalam tindanan media *arr. Ia bukan pengekstrak markdown. Bahagian mengenai etika di bawah menjelaskan mengapa perbezaan tersebut menentukan sama ada ia perlu dimasukkan ke dalam tindanan ejen anda atau tidak.

Mengapa kumpulan pelayar web menjadi punca kegagalan VPS berspesifikasi rendah

Setiap tab pelayar yang dibuka merupakan proses pemapar (renderer process) berasingan yang memegang DOM (document object model) dan heap JavaScript tersendiri. Oleh itu, penggunaan memori meningkat mengikut jumlah halaman yang dibuka pada satu-satu masa, bukan mengikut jumlah halaman yang dicapai setiap hari. Dua daripada projek ini menulis kos tersebut ke dalam fail compose masing-masing.

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

Fail compose Firecrawl mengehadkan bekas api miliknya pada 8 GB dan bekas Playwright miliknya pada 4 GB, dengan had swap yang sepadan. Fail compose Hound menetapkan 3 GB untuk satu bekas yang membawa Chromium terbina dalam. Ini adalah had siling yang dipilih oleh projek tersebut, iaitu angka yang diterbitkan dan bukannya ukuran sistem dalam keadaan melahu, manakala Redis, RabbitMQ, PostgreSQL dan FoundationDB masih memerlukan bahagian memori mereka di samping angka Firecrawl tersebut.

Had siling yang melebihi RAM yang anda miliki tidak memberi sebarang kesan. Apabila pelayan kehabisan memori, kernel out-of-memory killer akan menamatkan sesuatu proses, menyebabkan bekas tersebut hilang daripada docker compose ps tanpa sebarang ralat yang ditulis dalam log aplikasi. Baca dmesg -T | tail selepas sebarang but semula yang tidak dapat anda jelaskan. Peruntukkan 8 GB untuk keseluruhan stack Firecrawl dan anggap 4 GB sebagai tahap minimum untuk pelayan ujian. Penetapan angka bagi setiap servis diliputi dalam had memori dalam Docker Compose.

Satu lagi perincian pelayar web yang sering membuang masa pengguna. Docker memberikan bekas 64 MB memori kongsi pada /dev/shm, dan Chromium meletakkan penimbal pemapar di situ, menyebabkan ia terhempas (crash) pada halaman yang berat. Kedua-dua stack pelayar web tersebut meningkatkan had ini: fail compose Hound membawa shm_size: "1gb". Salin baris tersebut ke dalam mana-mana imej yang anda bina berasaskan Playwright.

Kualiti pengekstrakan pada halaman yang berat dengan JavaScript

Bagi HTML statik, blog yang dirender oleh pelayan, halaman dokumentasi, atau artikel berita, kesemuanya mengembalikan markdown yang hampir serupa dan yang terpantas akan menang. Perbezaan ketara muncul pada halaman yang dirender oleh klien, di mana HTML yang dihantar hanyalah kerangka kosong dan teks tiba daripada JavaScript selepas pemuatan selesai.

Draco meningkat mengikut peringkat. Peringkat 0 dan peringkat 1 menghuraikan HTML tanpa sebarang JavaScript. Peringkat 2 menjalankan JavaScript halaman itu sendiri di dalam V8 isolate dalam proses, iaitu enjin JavaScript tanpa pelayar di sekelilingnya, dan README menyatakan kod halaman tidak mendapat sebarang binding keupayaan hos di sana. Ini meliputi banyak aplikasi satu halaman (SPA) dengan sebahagian kecil daripada penggunaan memori pelayar. Apabila Draco menemui halangan yang tidak dapat dilalui, draco scrape akan keluar dengan kod 3, needs_browser. Semak perkara ini dalam skrip, kerana fail kosong dengan kod keluar sifar merupakan kegagalan yang merosakkan konteks ejen secara senyap:

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

Perkhidmatan playwright-service milik Firecrawl memacu Chromium sebenar, jadi ia merender apa yang dirender oleh pelayar. Binaan yang dihoskan sendiri (self-hosted) tetap bukan produk yang dihoskan: dokumentasi menyatakan instans yang dihoskan sendiri tidak mempunyai akses kepada Fire Engine, jadi ciri anti-blocking dan penggiliran IP perkhidmatan awan tiada, dan endpoint /agent serta /browser tidak disokong. Hound berada di antara kedua-duanya secara sengaja. Ia mengambil data melalui HTTP dan meningkat mengikut permintaan, dan pelayar hangatnya akan ditutup selepas tamat tempoh melahu, jadi pelayan yang tidak aktif kekal hampir pada tahap penggunaan asas.

Memasang Draco dengan versi yang ditetapkan (pinned)

README mendokumentasikan pemasang satu baris. Baca fungsinya sebelum menyalurkannya (pipe) ke shell: ia memasang ke $HOME/.draco/bin/draco, ia sentiasa mengambil keluaran latest, dan ia tidak menyemak sebarang tandatangan atau hash. Pada pelayan, tetapkan versi dan sahkan muat turun tersebut.

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

Itu akan mencetak draco-linux-x86-64.tar.gz: OK. Baris FAILED bermaksud bait yang anda pegang bukan bait yang diterbitkan oleh projek tersebut, jadi padamkannya dan mulakan semula.

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

Perintah terakhir mencetak halaman contoh sebagai markdown dalam masa kurang daripada satu saat. find bukan sekadar hiasan: susun atur arkib bukan sebahagian daripada kontrak awam projek, dan pemasang rasmi mencari binari dengan cara yang sama.

Jalankan daemon di bawah akaunnya sendiri dan bukannya pengguna log masuk anda. Tulis /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 menjawab sebaik sahaja daemon mendengar (listening). Connection refused bermaksud ia tidak mendengar, jadi baca journalctl -u draco -n 50. Punca biasa ialah proses lain sudah memegang port 3002, memandangkan itu juga port lalai Firecrawl, dan --port boleh mengubah salah satu daripadanya. Fail unit dengan lebih mendalam: unit perkhidmatan dan pemasa systemd.

Sekarang ambil cara ejen anda akan lakukan:

curl -X POST http://127.0.0.1:3002/v1/scrape \
  -H 'content-type: application/json' \
  -d '{"url": "https://example.com", "formats": ["markdown"]}'

Pastikan daemon fetch tidak terdedah kepada internet awam

API fetch tanpa pengesahan adalah proksi terbuka. Sesiapa sahaja yang boleh mencapai port tersebut akan menyebabkan pelayan anda membuat permintaan ke mana-mana URL di bawah alamat IP anda, dan laporan penyalahgunaan akan dihantar kepada penyedia perkhidmatan anda, bukan kepada mereka. serve flags yang didokumentasikan oleh Draco tidak menyertakan kunci API, jadi perlindungan mestilah dilakukan melalui rangkaian. Kekalkan 127.0.0.1 bind lalai apabila ejen berjalan pada mesin yang sama. Apabila ejen berada di tempat lain, letakkan kedua-dua hujung pada terowong peribadi; VPN WireGuard yang anda hos sendiri adalah penyelesaian biasa, dan lakukan bind pada alamat terowong dan bukannya 0.0.0.0. Kemudian, semak daripada mesin lain untuk memastikan IP awam tidak memberikan sebarang respons. asas firewall ufw dan akaun pengguna dengan keistimewaan minimum merangkumi kedua-dua aspek tersebut.

Adakah kod ejen anda akan berubah? Keserasian API dalam praktis

Draco menjawab laluan Firecrawl v1: /v1/scrape, /v1/map, /v1/crawl, /v1/batch/scrape dan /v1/search, dan README miliknya menyatakan bahawa medan yang tidak diketahui akan diterima dan diabaikan. Ejen yang sudah membuat hantaran ke /v1/scrape hanya memerlukan URL asas yang baharu dan tiada yang lain. Pantau perkara yang berubah di pihak sana: halaman self-hosting Firecrawl sendiri kini menguji dengan /v2/crawl, dan SDK semasa menggunakan v2, jadi klien v2 yang dihalakan ke Draco akan meminta laluan yang tidak diterbitkan oleh Draco. Uji setiap panggilan dengan curl sebelum anda menyunting kod ejen, dan baca badan JSON berbanding kod status, kerana nama medan adalah tempat di mana pelaksanaan ini mula berbeza.

Robots.txt, had kadar, dan garisan sempadan

Draco membaca robots.txt secara lalai, dan --ignore-robots mematikan fungsi tersebut. Firecrawl mendokumentasikan tetapan lalai yang sama. Biarkan kedua-duanya seperti asal. Kemudian, tetapkan kadar anda sendiri: --delay menetapkan milisaat antara permintaan dan --max-concurrency mengehadkan tugasan selari, dengan 8 sebagai nilai lalai daemon. Dua hingga empat adalah lebih baik untuk pautan VPS kongsi dan jarang sekali menjadi lebih perlahan secara keseluruhan, kerana tapak yang mula mengehadkan kadar anda akan memakan lebih banyak masa berbanding penjimatan daripada konkurensi. Simpan (cache) apa yang anda ambil, supaya larian ejen kali kedua tidak membebankan sumber asal. Itu juga merupakan item kos paling rendah dalam mengawal kos ejen AI anda.

Dinding cabaran (challenge walls) adalah subjek yang berasingan, dan Trawl dibina khusus untuk itu: Cloudflare Turnstile, reCAPTCHA, hCaptcha dan GeeTest. Dinding cabaran ialah tapak yang menolak trafik automatik secara terang-terangan. Mengatasi dinding tersebut meletakkan anda bertentangan dengan syarat penggunaan tapak, dan di sesetengah tempat bertentangan dengan undang-undang, jadi panduan ini hanya meliputi infrastruktur pengambilan data dan berhenti di situ. Teknik yang sama untuk melepasi dinding adalah teknik yang dipantau dan disekat oleh pemilik tapak, yang menjadikan mana-mana saluran paip (pipeline) yang dibina di atasnya rapuh dan tidak beretika. Apabila sesuatu sumber itu sangat penting, cari suapan RSS, API awam atau eksport pukalnya. Setiap satunya lebih murah untuk dijalankan dan tiada satu pun yang akan rosak apabila dinding cabaran tersebut berubah.

Sambungkannya kepada ejen melalui MCP

MCP (model context protocol) ialah antara muka yang digunakan oleh ejen untuk memanggil sesuatu alat. Draco membawa pelayan MCP dalam binari yang sama, melalui stdio:

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

Alat-alat tersebut kemudiannya muncul kepada ejen sebagai draco_scrape, draco_search dan set draco_interact_*. Stdio hanya berfungsi apabila proses ejen dan binari berada pada mesin yang sama, kerana pengangkutannya adalah input standard proses tersebut. Bagi ejen pada hos lain, Hound menyediakan MCP melalui HTTP sebagai ganti: hound --http --host 127.0.0.1 --port 8765 menerbitkan titik akhir pada http://127.0.0.1:8765/mcp, yang anda capai merentasi terowong. Pilihan pengangkutan dan perkara yang perlu didedahkan terdapat dalam menjalankan pelayan MCP pada VPS.

Mengambil pasangan dengan carian. Ejen yang hanya boleh mengambil data akan menunggu anda membekalkan URL. Tambahkan instans carian SearXNG yang dihoskan sendiri dan ia boleh mencarinya sendiri, dengan bentuk yang sama seperti kemahiran carian pelayar yang dibina di atas SearXNG. Sebaik sahaja daemon dihidupkan, ia menjadi satu perkhidmatan kongsi untuk mana-mana ejen AI yang dihoskan sendiri yang anda jalankan.

FAQ

Adakah saya memerlukan pelayar tanpa kepala (headless browser) untuk mengambil halaman bagi ejen AI?

Tidak untuk kebanyakan halaman. Dokumentasi, blog dan artikel berita yang dirender oleh pelayan akan dimuatkan sepenuhnya melalui pengambilan HTTP biasa ditambah dengan langkah penukaran HTML-ke-markdown. Inilah yang dilakukan oleh Draco pada peringkat rendahnya dengan kelajuan kira-kira 300 ms setiap halaman tanpa pelayar, berdasarkan angka projek itu sendiri. Pelayar hanya diperlukan untuk aplikasi yang dirender oleh klien, di mana HTML yang dihantar hanyalah kerangka kosong. V8 isolate milik Draco meliputi sebahagian besar keperluan tersebut tanpa proses pelayar, dan ia akan keluar dengan kod 3, needs_browser, apabila ia gagal melakukannya.

Berapakah jumlah RAM yang diperlukan oleh Firecrawl yang dihoskan sendiri pada VPS?

Fail compose-nya menetapkan had 8 GB pada kontena api dan 4 GB pada kontena Playwright, dan stack yang sama juga memulakan Redis, RabbitMQ, PostgreSQL dan FoundationDB. Sediakan 8 GB. Pada pelayan 2 GB, kernel out-of-memory killer akan membuang kontena di bawah beban, dan tanda pertama ialah kontena yang dimulakan semula dalam docker compose ps tanpa maklumat berguna dalam log aplikasi, jadi sahkan perkara ini dengan dmesg -T | tail.

Adakah Draco pengganti terus (drop-in replacement) untuk API Firecrawl?

Untuk endpoint v1, ia hampir sama. Ia menyediakan /v1/scrape, /v1/map, /v1/crawl, /v1/batch/scrape dan /v1/search, dan ia mengabaikan medan permintaan yang tidak dikenali, jadi klien yang ditulis untuk Firecrawl v1 biasanya hanya memerlukan URL asas yang baharu. Ia bukan produk yang dihoskan: tiada kumpulan proksi terurus di belakangnya, dan laluan v2 yang lebih baharu bagi Firecrawl bukan sebahagian daripada fungsinya. Sahkan setiap panggilan yang dibuat oleh ejen anda dengan curl terlebih dahulu.

Adakah menghoskan sendiri pengikis (scraper) bermakna saya boleh mengabaikan robots.txt?

Tidak. Tempat kod dijalankan tidak mengubah apa yang diterbitkan oleh tapak web atau apa yang dibenarkan oleh terma penggunaannya. Kedua-dua Draco dan Firecrawl menghormati robots.txt secara lalai, dan bendera pengabaian (override flag) wujud untuk tapak yang anda miliki atau mempunyai kebenaran bertulis untuk dikikis. Had kadar (rate limits) tetap dikuatkuasakan di hujung pelayan tanpa mengira keadaan, jadi --delay yang berhemah dengan konkurensi rendah akan memastikan alamat IP anda terus berfungsi. Stack yang hanya berfungsi dengan menewaskan tembok cabaran (challenge wall) adalah stack yang akan rosak tanpa amaran.