Kebanyakan orang menaruh Firecrawl sejajar dengan library scraping — gaya pip install, tulis skrip, selesai. Cara pandang itu keliru, dan bedanya penting bahkan sebelum Anda mengetik satu perintah pun. Firecrawl self-hosted bukan library yang di-import; ini adalah layanan yang Anda operasikan, dan untuk menjalankannya Anda harus menyalakan enam container Docker yang saling terhubung.
Saya menjalankan stack self-hosted ini di Mac (arm64, Docker lewat colima) tanpa cloud key, mengarahkan endpoint /v1/scrape ke beberapa situs demo yang ramah terhadap scraping, lalu melihat apa yang kembali. Ringkasan singkatnya: janji utamanya terbukti — sebuah halaman masuk, lalu keluar Markdown yang rapi dan siap untuk LLM — tetapi dari semua alat yang saya uji untuk riset ini, inilah setup yang paling berat. Ini adalah tinjauan sementara, bukan penilaian final, dan saya akan jelaskan dengan jujur apa saja yang saya uji dan apa yang belum.
Firecrawl Adalah Layanan, Bukan Library
Ini model mental pertama yang perlu diluruskan. Alat scraping yang biasa dipakai developer umumnya adalah library: Anda menambahkan dependency, memanggil fungsi, lalu mendapatkan HTML atau data terurai di dalam proses Anda sendiri. Firecrawl self-hosted berbeda. Ini platform yang berjalan sebagai layanan, punya API sendiri, dan Anda mengaksesnya lewat HTTP.
Posisi resminya adalah "API untuk mencari, scraping, dan berinteraksi dengan web dalam skala besar," dan bentuk produknya memang seperti itu — halaman masuk, lalu keluar Markdown bersih atau data terstruktur. Saat self-host, Anda tidak menautkan Firecrawl ke aplikasi Anda. Anda menyalakan stack docker compose dan memanggil sebuah endpoint, sama seperti memanggil microservice internal mana pun.
Stack yang saya jalankan terdiri dari enam layanan:
- api — permukaan HTTP yang benar-benar Anda panggil
- playwright-service — browser headless untuk rendering JavaScript
- redis — antrean dan cache
- rabbitmq — message broker
- nuq-postgres — varian Postgres untuk status job
- foundationdb — penyimpanan key-value terdistribusi
Itu backend sungguhan, bukan sekadar skrip pembantu. Redis, RabbitMQ, Postgres, dan FoundationDB masing-masing adalah infrastruktur kelas industri. Keuntungannya, Firecrawl menangani bagian yang ribet dari scraping — antrean, rendering, retry — lewat satu panggilan API. Konsekuensinya, Anda kini harus mengoperasikan keenam container itu. Simpan trade-off ini di kepala; ini benang merah dari seluruh ulasan ini.
Sebagai referensi, saya menguji dengan SDK firecrawl-py 4.32.0 dan firecrawl-js 4.30.0, dengan menarik image resmi prebuilt ghcr.io/firecrawl/firecrawl:latest pada 2026-07-09. Pada tanggal itu repositorinya berada di kisaran 148 ribu bintang (anggap saja metadata, bukan skor kualitas), di bawah lisensi AGPL-3.0 — detail yang akan saya bahas lagi karena sangat memengaruhi penggunaan komersial.
Uji Inti: Halaman Berubah Menjadi Markdown Bersih
Alasan utama Firecrawl ada adalah mengubah halaman web menjadi Markdown yang benar-benar bisa dibaca LLM. Jadi itu hal pertama yang saya cek.
Saya mengarahkan /v1/scrape ke books.toscrape.com, katalog statis yang dibuat khusus untuk latihan scraping. Hasilnya: 9.222 karakter Markdown yang bersih dan siap untuk LLM, dengan judul halaman All products | Books to Scrape terurai dengan tepat. Bukan HTML mentah yang dibuang ke string — melainkan Markdown terstruktur, lengkap dengan heading, tautan, dan referensi gambar. Jenis output yang bisa langsung dimasukkan ke retrieval pipeline atau diberikan ke model tanpa perlu dibersihkan lagi.
Inilah kekuatan utama Firecrawl, dan versi self-hosted-nya berhasil mengeksekusi itu tanpa drama. Jika tugas Anda adalah "beri saya inti halaman ini dalam bentuk Markdown yang mudah dibaca," halaman statis kembali persis seperti yang dijanjikan. Itu primitif yang sangat berguna, dan itulah alasan alat ini punya banyak pengguna.
Perlu tepat soal cakupan: saya hanya menguji jalur /v1/scrape untuk satu halaman. Saya tidak menguji /v1/crawl, crawler multi-halaman yang menyusuri seluruh situs. Itu kemampuan berbeda dengan mode kegagalannya sendiri, dan saya tidak akan mengklaim sesuatu bekerja kalau memang belum saya jalankan.
Halaman JavaScript: Browser Bawaan Memang Layak Dipakai
Halaman statis adalah kasus mudah. Pertanyaan yang lebih sulit untuk scraper apa pun adalah apa yang terjadi ketika konten baru muncul setelah JavaScript dijalankan — dan di web modern, itulah mayoritas kasus.
Di sinilah container playwright-service berhenti terasa seperti beban dan mulai terasa sebagai inti manfaatnya. Saya mengarahkan scraper ke quotes.toscrape.com/js/, versi demo site yang merender kutipannya di sisi klien. Jika Firecrawl hanya mengambil HTML mentah, kutipannya tidak akan ada — karena konten itu memang baru ada setelah browser menjalankan skrip halaman.
Hasil scrape kembali dengan 1.574 karakter Markdown, dan kutipan Einstein ada di dalamnya. Kutipan itu adalah konten pasca-JavaScript: kemunculannya membuktikan bahwa playwright-service benar-benar merender halaman di mesin browser sungguhan sebelum mengekstrak teks, bukan sekadar mengambil shell kosong sebelum render.
Jadi salah satu dari enam container itu memang browser headless, dan ia menjalankan tugas yang memang seharusnya ia lakukan. Inilah justifikasi konkret untuk arsitektur yang lebih berat: Anda bukan cuma membayar container, tapi membayar kemampuan merender halaman yang sarat JavaScript tanpa harus membangun otomasi browser sendiri. Untuk banyak target dunia nyata, itulah perbedaan antara hasil yang berguna dan div kosong.
Saat Target Buruk: Error Terstruktur, Bukan Crash
Scraper menghabiskan banyak waktunya pada hal-hal yang gagal — host mati, URL salah ketik, server yang hang. Cara alat gagal sama pentingnya dengan cara alat berhasil.
Saya sengaja memasukkan host yang invalid ke API. Yang kembali adalah HTTP 500 yang terstruktur dan proses tetap berjalan — tidak ada stack trace yang muncrat ke client, tidak ada container yang tumbang, tidak ada proses yang menggantung. Error-nya kembali sebagai respons bersih yang bisa ditangani oleh pemanggil.
Itu perilaku yang sederhana tapi benar, dan justru itulah yang Anda inginkan dari sesuatu yang akan masuk ke pipeline. Scraper yang panic saat target bermasalah adalah scraper yang tidak bisa diotomatisasi dengan aman. Yang ini mengembalikan error yang bisa Anda tangkap lalu lanjut ke item berikutnya. Saya hanya menguji satu skenario error, jadi anggap ini sebagai "satu failure yang saya lempar ditangani dengan benar," bukan audit ketahanan yang menyeluruh — tetapi satu data point itu memberi hasil yang tepat.
Realitas Setup: Pekerjaan Paling Berat di Base Ini
Sekarang bagian yang tidak pernah masuk screenshot untuk tweet peluncuran. Firecrawl self-hosted, tanpa berlebihan, adalah setup paling rumit dari semua alat di research base ini — dan saya sudah menyalakan cukup banyak di antaranya.
Enam container saja sudah menjadi biaya dasar. Tapi saya juga menemui dua hambatan dalam prosesnya, dan saya ingin akurat soal siapa yang salah — ternyata bukan Firecrawl.
Hambatan pertama: build dari source. Membangun image dari source gagal di dalam VM colima saya karena error snapshotter pada containerd. Itu adalah interaksi yang memang kadang bermasalah antara proses build dan storage layer colima — gangguan infrastruktur di lingkungan saya, bukan bug Firecrawl. File compose mendokumentasikan alternatif: gunakan image prebuilt resmi ghcr.io/firecrawl/* alih-alih build lokal. Saya beralih ke opsi itu, dan seluruh stack naik dengan bersih. Jika Anda memakai Docker daemon standar alih-alih colima, Anda mungkin tidak akan menemui masalah ini sama sekali; saya menandainya sebagai catatan lingkungan, dan validasi build kontributor pada daemon yang bersih ada di daftar hal yang belum saya tutup.
Hambatan kedua: SSRF guard. Scrape pertama saya diblokir oleh perlindungan private-IP / SSRF Firecrawl. Kenapa? Jaringan colima memetakan hostname publik ke alamat 198.18.x.x, yang berada dalam rentang reservasi dan dengan benar dianggap Firecrawl sebagai alamat privat — jadi lapisan keamanannya bekerja sebagaimana mestinya dan menolak mengambil target yang tampak internal. Untuk mengatasinya hanya untuk pengujian lokal, saya mengatur ALLOW_LOCAL_WEBHOOKS=true.
Flag itu bisa disalin ke production dan menimbulkan insiden, jadi perlu dijelaskan dengan sangat jelas: SSRF guard adalah fitur, bukan hambatan. Itu yang mencegah layanan scraping tertipu untuk mengakses jaringan internal Anda. Saya mematikannya karena keunikan DNS colima membuat target publik yang sah terlihat privat di dalam VM. Jangan pernah menonaktifkan perlindungan SSRF dalam deployment nyata. Jika Anda mengambil satu catatan operasional dari ulasan ini, ambil yang ini.
Dua hambatan itu, jujur saja, adalah artefak menjalankan Docker lewat colima di laptop — bukan cacat perangkat lunaknya. Di sisi lain, beratnya setup itu sendiri memang nyata dan memang bagian dari desain Firecrawl. Ini bukan alat yang Anda pilih saat ingin skrip lokal cepat; ini alat yang Anda siapkan ketika Anda ingin layanan scraping yang mampu merender dan Anda bersedia mengoperasikan infrastrukturnya.
Apa yang Tidak Saya Uji, dan Apa yang Tidak Disediakan
Berikut hal-hal yang tidak saya cakup, dan hal-hal yang memang tidak diberikan oleh alat ini.
Self-hosted tidak punya Fire-engine. Produk cloud Firecrawl menyertakan Fire-engine, lapisan anti-block miliknya yang bersifat proprietary untuk menembus pertahanan bot. Menurut SELF_HOST.md proyek itu sendiri, instance self-hosted tidak mendapatkannya. Jadi kalau Anda membayangkan Firecrawl self-hosted bisa langsung menembus sistem anti-bot agresif, harap ubah gambaran itu — kemampuan tersebut ada di tier cloud, dan bukan bagian dari yang saya jalankan.
API cloud tidak diuji di sini. Saya tidak punya cloud key, jadi semua yang dibahas di atas hanya stack self-hosted. Layanan cloud terkelola — dengan Fire-engine, scaling yang di-host, dan fitur AI — adalah produk yang berbeda, dan saya tidak akan menilai performanya dari luar. Anggap klaim apa pun soal cloud berada di luar cakupan ulasan ini.
Fitur AI butuh key. Format output terstruktur json dan endpoint /extract bergantung pada LLM, yang berarti Anda perlu membawa OpenAI key sendiri atau menghubungkannya ke Ollama. Saya tidak menguji jalur itu, jadi /extract dan output json terstruktur juga masuk kolom yang belum teruji.
Proxy itu catatan tambahan, bukan judul utama. Firecrawl mendukung konfigurasi proxy, tetapi saya sengaja menaruhnya sebagai catatan kaki — itu pengaturan yang bisa Anda putar, bukan alasan utama memilih alat ini, dan self-hosted tetap tidak memiliki lapisan anti-block milik cloud.
AGPL-3.0 adalah keputusan kepatuhan yang nyata. Poin ini layak mendapat pembahasan tersendiri.
Lisensi: Baca AGPL-3.0 Sebelum Anda Rilis
Firecrawl dilisensikan di bawah AGPL-3.0. Ini bukan sekadar kalimat kecil di bagian bawah README — ini adalah copyleft kuat dengan klausul penggunaan lewat jaringan, dan itu bisa langsung memengaruhi apakah Anda boleh membangun produk komersial di atas instance self-hosted.
Versi singkatnya: kewajiban standar GPL muncul saat distribusi. AGPL melangkah lebih jauh — klausul penggunaan jaringan berarti menyediakan fungsi perangkat lunak kepada pengguna lewat jaringan bisa dihitung sebagai jenis penggunaan yang membawa kewajiban menyediakan source code. Jika Anda menanam Firecrawl self-hosted di dalam layanan yang diakses pelanggan Anda lewat internet, klausul itu jelas relevan, dan "kami tidak pernah mengirim binary" bukan jalan keluar yang sering diasumsikan orang.
Saya bukan pengacara Anda, dan interpretasi lisensi bergantung pada cara tepat Anda melakukan deployment. Tetapi untuk rekomendasi komersial apa pun, AGPL-3.0 adalah pertimbangan utama, bukan tulisan kecil di bagian akhir. Libatkan pihak yang menangani lisensi di perusahaan Anda sebelum membangun di atasnya. Menyebut ini bukan berarti Firecrawl buruk — banyak alat hebat memakai AGPL — hanya saja ini fakta yang harus Anda letakkan di meja sejak awal.
Di Mana Stack Developer Thunderbit Cocok
Coba Thunderbit untuk Ekstraksi Data Web
Kalau tujuan Anda sebenarnya adalah "halaman → Markdown siap LLM" atau "halaman → data terstruktur," dan pajak operasional enam container plus pertanyaan AGPL bukan sesuatu yang ingin Anda tanggung, itulah celah yang memang diisi oleh stack developer Thunderbit. Mesin AI yang sama di balik 100.000+ pengguna ekstensi kami, diekspos dalam tiga cara untuk pekerjaan teknis — sementara infrastrukturnya tetap kami tanggung di sisi kami.
- Open API (REST).
POST /distillmengubah halaman menjadi Markdown yang bersih dan siap untuk LLM;POST /extractmenghasilkan data terstruktur berdasarkan JSON Schema yang Anda definisikan. Rendering JS, penanganan anti-bot, dan konten dinamis diproses di server — Anda tidak perlu menjalankan container browser sendiri. FlagrenderMode(none/basic/full) mengatur seberapa kuat render dilakukan, dan endpoint batch mendukung hingga 100 URL untuk distill. - MCP server. Server resmi Model Context Protocol sehingga agen AI di Claude atau Cursor bisa scraping di tengah pekerjaan:
thunderbit_suggest_fieldsuntuk merencanakan ekstraksi (gratis),thunderbit_distilluntuk Markdown,thunderbit_extractuntuk data terstruktur. Agen memutuskan kapan mengambil data tanpa keluar dari lingkungannya. - CLI.
npx -y @thunderbit/thunderbit-climenjalankan scrape dari terminal, skrip, CI, atau cron — tanpa browser, tanpa stack yang harus Anda rawat. Langsung alirkan ke alat lain:thunderbit distill "$URL" -f markdown | claude -p "summarise".
Perbandingannya dengan Firecrawl self-hosted cukup jelas. Firecrawl self-hosted memberi Anda kontrol penuh sekaligus tanggung jawab operasional penuh: enam container, beban setup, syarat AGPL, dan tanpa Fire-engine untuk anti-block. Thunderbit API/MCP/CLI menukar kontrol itu dengan engine hosted yang mengembalikan JSON terstruktur yang cocok dengan schema — bukan sekadar Markdown mentah — sementara container, lapisan anti-bot, dan kewajiban copyleft diambil dari pundak Anda. Alat berbeda untuk selera infrastruktur yang berbeda.
Begini trade-off-nya dalam satu tampilan:
| Pertimbangan | Firecrawl self-hosted | Stack developer Thunderbit (API · MCP · CLI) |
|---|---|---|
| Bentuk deployment | Layanan yang Anda operasikan (6 container) | API hosted yang Anda panggil |
| Untuk mulai berjalan | docker compose menyalakan stack 6 layanan | API key, lalu request |
| Rendering JS | playwright-service bawaan (Anda yang menjalankan) | Server-side, flag renderMode |
| Output terstruktur | Butuh LLM key (/extract, json) | POST /extract dengan JSON Schema |
| Lapisan anti-bot | Tidak ada di self-hosted (Fire-engine hanya cloud) | Ditangani di server |
| Lisensi | AGPL-3.0 (copyleft untuk penggunaan jaringan) | API komersial, tanpa copyleft pada kode Anda |
| Paling cocok bila | Anda ingin kontrol penuh dan siap menjalankan infra | Anda ingin Markdown/data terstruktur tanpa ops |
Tidak ada yang secara universal "lebih baik." Jika menjalankan platform itu sendiri memang tujuan Anda — kontrol penuh atas data, tanpa ketergantungan eksternal, dan AGPL cocok dengan situasi Anda — Firecrawl self-hosted adalah pilihan yang kapabel dan masih aktif dikembangkan. Jika Anda lebih suka memanggil API dan melewatkan hidup dengan enam container, itulah proposisi Thunderbit stack.
Siapa yang Sebenarnya Perlu Self-Host Firecrawl
Kalau hype-nya disingkirkan, gambarnya cukup jelas untuk dibagi berdasarkan kebutuhan.
Self-host Firecrawl jika Anda ingin kontrol penuh atas infrastruktur scraping Anda, Anda nyaman mengoperasikan Redis / RabbitMQ / Postgres / FoundationDB di production, kebutuhan rendering Anda memang membenarkan container playwright-service, dan AGPL-3.0 cocok dengan cara deployment Anda. Kemampuan intinya nyata: saya mendapatkan Markdown yang bersih, terstruktur, dan siap LLM dari halaman statis maupun halaman yang dirender JavaScript, dan seluruh stack berjalan memakai image prebuilt.
Cari opsi lain jika Anda ingin skrip lokal yang cepat (ini setup paling berat di base ini, titik), Anda butuh anti-block kelas cloud tanpa mengoperasikannya sendiri (self-host tidak punya Fire-engine), atau klausul penggunaan jaringan AGPL berbenturan dengan rencana komersial Anda. Untuk kasus "saya cuma butuh Markdown atau data terstruktur dari sebuah URL, tanpa urusan operasional," API hosted seperti /distill dan /extract milik Thunderbit menutup kebutuhan yang sama tanpa container.
Pembacaan sementara saya: inti produknya kuat, komitmen operasionalnya berat, dan lisensinya harus Anda bereskan sebelum dipakai secara komersial. Ini pantas untuk tim yang ingin memiliki seluruh pipeline — dan memang meminta banyak dari yang lain. Saya akan meninjau ulang setelah saya menjalankan /v1/crawl, mencoba /extract dengan LLM key, dan memvalidasi build dari source pada daemon non-colima; itulah pertanyaan yang masih terbuka antara tinjauan ini dan keputusan final.
Coba Thunderbit untuk Ekstraksi Data Web Get Started Free
FAQ
Apakah Firecrawl self-hosted sama dengan versi cloud?
Tidak. Self-hosted memberi Anda mesin inti untuk mengubah halaman menjadi Markdown dan rendering JavaScript lewat playwright-service bawaan, tetapi tidak menyertakan Fire-engine, yaitu lapisan anti-block proprietary milik produk cloud. Fitur AI seperti endpoint /extract dan output json juga membutuhkan LLM key milik Anda sendiri (OpenAI atau Ollama). Dalam ulasan ini saya hanya menguji stack self-hosted; API cloud berada di luar cakupan.
Berapa banyak container yang benar-benar dibutuhkan Firecrawl self-hosted? Enam: api, playwright-service, redis, rabbitmq, nuq-postgres, dan foundationdb. Ini stack layanan penuh, bukan satu binary — itulah sebabnya ia menjadi setup paling berat di antara semua alat dalam research base ini. Siapkan overhead operasional untuk menjalankan message broker, cache, dan infrastruktur database, bukan sekadar skrip.
Bisakah Firecrawl menangani halaman yang sangat bergantung pada JavaScript saat self-hosted? Ya, berdasarkan pengujian saya. playwright-service bawaan merender halaman di mesin browser sungguhan sebelum ekstraksi. Saya memastikannya di quotes.toscrape.com/js/, tempat kutipan Einstein — konten yang baru ada setelah JavaScript berjalan — muncul di Markdown hasil keluaran. Kemampuan rendering inilah alasan salah satu dari enam container tersebut adalah browser headless.
Apakah lisensi AGPL-3.0 memengaruhi penggunaan komersial? Bisa, dan Anda sebaiknya menganggap ini sebagai pertanyaan tingkat pertama. AGPL-3.0 adalah copyleft kuat dengan klausul penggunaan jaringan, yang berarti menyediakan fungsi perangkat lunak kepada pengguna lewat jaringan dapat membawa kewajiban menyediakan source code — bahkan jika Anda tidak pernah mendistribusikan binary. Jika Anda berencana membangun produk komersial di atas instance self-hosted, bicarakan dengan pihak yang menangani lisensi di perusahaan Anda sebelum melangkah lebih jauh. Ulasan ini hanya menandai lisensinya; ini bukan nasihat hukum.
Apa bedanya Firecrawl dengan tool developer milik Thunderbit?
Firecrawl self-hosted adalah layanan yang Anda operasikan — enam container yang Anda jalankan sendiri, dengan syarat AGPL-3.0 dan tanpa lapisan anti-block bawaan. Stack developer Thunderbit (Open API, MCP server, CLI) adalah engine hosted yang Anda panggil: POST /distill untuk Markdown, POST /extract untuk data terstruktur berbasis JSON Schema, dengan rendering JS dan penanganan anti-bot di server serta tanpa kewajiban copyleft pada kode Anda sendiri. Firecrawl cocok untuk tim yang ingin kontrol penuh atas infrastruktur; Thunderbit cocok untuk mereka yang ingin hasilnya tanpa beban operasional.
