Kebanyakan orang menganggap Firecrawl itu cuma library buat scraping—tinggal install pakai pip, bikin script dikit, beres. Padahal, pemahaman ini salah kaprah banget, dan bedanya itu krusial sebelum kamu ngetik satu perintah pun. Firecrawl yang di-hosting sendiri itu bukan library yang kamu import; ini adalah layanan yang kamu jalankan, dan buat menjalankannya, kamu butuh enam container Docker yang saling ngobrol.
Saya nyoba stack yang di-hosting sendiri di Mac (arm64, Docker via colima) tanpa kunci cloud, ngarahin endpoint /v1/scrape ke beberapa situs demo yang ramah scraping, terus ngeliat hasilnya. Singkatnya: janji utamanya terpenuhi—satu halaman masuk, terus keluar jadi Markdown bersih yang siap LLM—tapi setup-nya itu yang paling ribet dari semua alat yang saya uji di riset ini. Ini baru tinjauan awal, bukan peringkat final, dan saya bakal jelasin detail apa aja yang saya uji dan enggak.
Firecrawl Itu Layanan, Bukan Library
Ini dia model mental yang harus diluruskan duluan. Alat scraping yang paling sering dipakai developer itu biasanya library: kamu nambahin dependency, manggil fungsi, terus dapet HTML atau data yang udah di-parse di proses kamu sendiri. Firecrawl yang di-hosting sendiri itu beda. Ini adalah platform yang jalan dengan API-nya sendiri, dan kamu komunikasi sama dia via HTTP.
Posisi resminya bilang "API buat nyari, scrape, dan interaksi sama web dalam skala besar," dan bentuk produknya emang persis kayak gitu—halaman masuk, Markdown bersih atau data terstruktur keluar. Pas kamu hosting sendiri, kamu enggak link ke Firecrawl. Kamu jalanin stack docker compose dan manggil endpoint, sama kayak kamu manggil microservice internal lainnya.
Stack yang saya jalanin itu terdiri dari enam layanan:
- api — antarmuka HTTP yang beneran kamu panggil
- playwright-service — headless browser buat rendering JavaScript
- redis — queue dan cache
- rabbitmq — message broker
- nuq-postgres — varian Postgres buat status pekerjaan
- foundationdb — distributed key-value store
Itu backend beneran, bukan script pembantu. Redis, RabbitMQ, Postgres, dan FoundationDB itu semua infrastruktur kelas industri. Keuntungannya, Firecrawl ngurusin bagian scraping yang ribet—queue, rendering, retry—di balik satu panggilan API. Biayanya, kamu sekarang harus ngurusin enam container itu. Ingat trade-off ini; ini inti dari seluruh ulasan ini.
Sebagai referensi, saya nguji pakai SDK firecrawl-py 4.32.0 dan firecrawl-js 4.30.0, narik image resmi ghcr.io/firecrawl/firecrawl:latest yang udah jadi pada 2026-07-09. Repository ini punya sekitar 148 ribu bintang pada tanggal itu (anggap aja metadata, bukan skor kualitas), di bawah lisensi AGPL-3.0—detail yang bakal saya bahas nanti, karena ini ngubah perhitungan buat penggunaan komersial.
Uji Coba Utama: Halaman Jadi Markdown Bersih
Seluruh alasan Firecrawl ada itu buat ngubah halaman web jadi Markdown yang bisa dibaca LLM. Jadi itu hal pertama yang saya cek.
Saya ngarahin /v1/scrape ke books.toscrape.com, katalog statis yang emang dibikin buat latihan scraping. Hasilnya: 9.222 karakter Markdown bersih, siap LLM, dengan judul halaman All products | Books to Scrape yang di-parse dengan bener. Bukan HTML mentah yang dibuang ke string—ini Markdown terstruktur, dengan judul, link, dan referensi gambar yang utuh. Tipe output yang bisa kamu masukin langsung ke pipeline retrieval atau kasih ke model tanpa perlu bersih-bersih lagi.
Ini kekuatan utama Firecrawl, dan yang di-hosting sendiri nyediain itu tanpa masalah. Kalo tugas kamu "kasih saya substansi yang bisa dibaca dari halaman ini sebagai Markdown," halaman statis balik persis kayak yang diiklanin. Itu primitif yang bener-bener berguna, dan itu alasan kenapa alat ini punya banyak pengikut.
Penting buat akurat soal cakupannya: Saya pakai jalur /v1/scrape satu halaman. Saya enggak nguji /v1/crawl, crawler multi-halaman yang menjelajahi seluruh situs. Itu kemampuan terpisah dengan mode kegagalannya sendiri, dan saya enggak bakal ngaku itu berfungsi kalo saya enggak ngejalaninnya.
Halaman JavaScript: Browser yang Dibundel Membuktikan Nilainya
Halaman statis itu kasus gampang. Pertanyaan yang lebih susah buat scraper adalah apa yang terjadi kalo kontennya cuma muncul setelah JavaScript jalan—yang, di web modern, terjadi hampir sepanjang waktu.
Di sinilah container playwright-service berhenti jadi overhead dan mulai jadi intinya. Saya ngarahin scraper ke quotes.toscrape.com/js/, versi situs demo yang render kutipannya di sisi client. Kalo Firecrawl cuma ngambil HTML mentah, kutipannya enggak bakal ada—kutipan itu enggak ada sampai browser ngeksekusi script halaman.
Scrape balik dengan 1.574 karakter Markdown, dan kutipan Einstein ada di dalamnya. Kutipan itu adalah konten pasca-JavaScript: kehadirannya adalah bukti bahwa playwright-service bener-bener render halaman di mesin browser sungguhan sebelum ngekstrak teks, daripada ngambil shell pra-render yang kosong.
Jadi salah satu dari enam container itu adalah headless browser, dan dia ngelakuin kerjaan yang kamu mau. Itu justifikasi konkret buat arsitektur yang lebih berat: kamu enggak cuma bayar buat container, kamu bayar buat kemampuan render halaman yang banyak pakai JS tanpa perlu nyiapin otomatisasi browser kamu sendiri. Buat banyak target dunia nyata, itulah bedanya antara output yang bisa dipakai dan div kosong.
Ketika Target Buruk: Kesalahan Terstruktur, Tidak Ada Crash
Scraper ngabisin sebagian besar hidupnya buat nunjuk ke hal-hal yang enggak berfungsi—host mati, URL salah ketik, server macet. Gimana sebuah alat gagal itu sama pentingnya dengan gimana dia berhasil.
Saya sengaja ngasih host yang enggak valid ke API. Dia ngembaliin HTTP 500 terstruktur dan terus jalan—enggak ada stack trace yang dimuntahin ke client, enggak ada container yang jatuh, enggak ada proses yang macet. Kesalahan balik sebagai respons bersih yang bisa ditindaklanjuti sama pemanggil.
Itu perilaku membosankan dan bener yang kamu mau dari sesuatu yang bakal kamu masukin ke pipeline. Scraper yang panik pada target yang buruk adalah scraper yang enggak bisa kamu otomatisasi. Yang satu ini ngembaliin kesalahan yang bisa kamu tangkap dan lanjutkan. Saya cuma nguji satu kasus kesalahan, jadi baca ini sebagai "menangani satu kegagalan yang saya kasih dengan bener," bukan audit ketahanan yang menyeluruh—tapi satu titik data adalah hasil yang bener.
Realitas Pengaturan: Beban Terberat dalam Basis
Sekarang bagian yang enggak ada yang ngambil screenshot buat tweet peluncuran. Firecrawl yang di-hosting sendiri, tanpa melebih-lebihkan, adalah setup yang paling ribet dari semua alat di riset ini—dan saya udah nyiapin banyak di antaranya.
Enam container itu biaya dasar. Tapi saya juga ngalamin dua hambatan di jalan, dan saya pengen akurat soal siapa yang salah—bukan Firecrawl, ternyata.
Hambatan pertama: build dari sumber. Build image dari sumber gagal di dalam VM colima saya karena kesalahan snapshotter containerd. Itu interaksi yang diketahui enggak stabil antara build dan lapisan penyimpanan colima—cegukan infrastruktur di lingkungan saya, bukan bug di Firecrawl. File compose mendokumentasikan alternatif: pakai image resmi ghcr.io/firecrawl/* yang udah jadi daripada build secara lokal. Saya beralih ke itu, dan seluruh stack muncul dengan bersih. Kalo kamu pakai daemon Docker standar daripada colima, kamu mungkin enggak bakal ngeliat ini sama sekali; saya nandainnya sebagai peringatan lingkungan, dan validasi build kontributor pada daemon bersih ada di daftar celah saya.
Hambatan kedua: penjaga SSRF. Scrape pertama saya diblokir sama IP pribadi Firecrawl / perlindungan SSRF. Kenapa? Jaringan colima memetakan hostname publik ke alamat 198.18.x.x, yang ada di rentang yang dicadangkan yang bener-bener diperlakukan Firecrawl sebagai pribadi—jadi lapisan keamanannya ngelakuin tugasnya dan nolak buat ngambil apa yang keliatan kayak target internal. Buat ngatasin ini cuma buat pengujian lokal, saya nyetel ALLOW_LOCAL_WEBHOOKS=true.
Flag itu di-copy-paste ke produksi dan nyebabin insiden, jadi akuratlah soal apa itu: penjaga SSRF itu fitur, bukan hambatan. Itulah yang ngehentiin layanan scraping biar enggak ketipu buat nyerang jaringan internal kamu. Saya matiin itu karena keanehan DNS colima bikin target publik saya yang sah keliatan pribadi di dalam VM. Jangan matiin perlindungan SSRF dalam penerapan nyata. Kalo kamu ngambil satu catatan operasional dari ulasan ini, ambillah yang itu.
Kedua hambatan, jujur aja, adalah artefak ngejalanin Docker via colima di laptop—bukan cacat pada software. Di sisi lain, bobot setup itu sendiri nyata dan itu milik Firecrawl berdasarkan desain. Ini bukan alat yang kamu pakai pas kamu pengen script lokal cepet; ini adalah alat yang kamu siapin pas kamu pengen layanan scraping yang mampu render dan kamu bersedia ngejalanin infrastruktur buat itu.
Apa yang Tidak Saya Uji, dan Apa yang Tidak Dilakukannya
Ini dia apa yang enggak saya bahas, dan apa yang enggak dikasih sama alat ini.
Yang di-hosting sendiri enggak punya Fire-engine. Produk cloud Firecrawl nyakup Fire-engine, lapisan anti-blokir miliknya buat ngelewatin pertahanan bot. Sesuai sama SELF_HOST.md proyek itu sendiri, instance yang di-hosting sendiri enggak dapet itu. Jadi kalo kamu ngebayangin Firecrawl yang di-hosting sendiri nembus sistem anti-bot agresif di luar kotak, sesuaikan gambarannya—kemampuan itu ada di tingkat cloud, dan itu bukan bagian dari apa yang saya jalanin.
API cloud enggak diuji di sini. Saya enggak punya kunci cloud, jadi semua yang di atas cuma stack yang di-hosting sendiri. Layanan cloud terkelola—dengan Fire-engine, scaling yang di-hosting, dan fitur AI—adalah produk yang beda, dan saya enggak bakal ngarakterisasi kinerjanya dari luar. Perlakukan klaim cloud apa pun sebagai di luar cakupan ulasan ini.
Fitur AI butuh kunci. Format output terstruktur json dan endpoint /extract bergantung pada LLM, yang berarti bawa kunci OpenAI atau nyambungin Ollama. Itu nempatin pilihan model ke dalam daftar bahan: sebelum berkomitmen pada setup, bandingkan harga API saat ini dari penyedia yang bisa kamu pakai. Saya enggak pakai jalur itu, jadi /extract dan output json terstruktur juga ada di kolom yang enggak diuji.
Proxy adalah peringatan, bukan berita utama. Firecrawl mendukung konfigurasi proxy, tapi saya sengaja nyantuminnya sebagai catatan kaki—itu adalah knob yang bisa kamu putar, bukan alasan buat milih alat, dan yang di-hosting sendiri masih kekurangan lapisan anti-blokir cloud terlepas dari itu.
AGPL-3.0 adalah keputusan kepatuhan yang nyata. Yang satu ini pantes dapet bagiannya sendiri.
Lisensi: Baca AGPL-3.0 Sebelum Kamu Ngirim
Firecrawl dilisensikan di bawah AGPL-3.0. Itu bukan baris yang dibuang di bagian bawah README—itu adalah copyleft yang kuat dengan klausul penggunaan jaringan, dan itu bisa secara langsung memengaruhi apakah kamu bisa bikin produk komersial di atas instance yang di-hosting sendiri.
Singkatnya: kewajiban GPL standar memicu pada distribusi. AGPL melangkah lebih jauh—ketentuan penggunaan jaringan berarti nawarin fungsionalitas software ke pengguna via jaringan bisa dihitung sebagai tipe penggunaan yang bawa kewajiban ketersediaan sumber. Kalo kamu nyematin Firecrawl yang di-hosting sendiri di dalam layanan yang dijangkau pelanggan kamu via internet, klausul itu ada dalam cakupan, dan "kami enggak pernah ngirim binary" itu bukan jalan keluar yang diasumsikan orang.
Saya bukan pengacara kamu, dan interpretasi lisensi tergantung pada gimana persisnya kamu menerapkan. Tapi buat rekomendasi komersial apa pun, AGPL-3.0 adalah pertimbangan kelas satu, bukan cetakan kecil. Libatkan siapa pun yang ngurus lisensi di perusahaan kamu sebelum kamu bikin. Nandain ini bukan kritik terhadap Firecrawl—banyak alat hebat itu AGPL—itu cuma fakta yang perlu kamu tahu dari awal.
Di Mana Stack Developer Thunderbit Cocok
Coba Thunderbit untuk Ekstraksi Data Web
Kalo tujuan kamu sebenernya adalah "halaman → Markdown siap LLM" atau "halaman → data terstruktur," dan biaya operasional enam container ditambah pertanyaan AGPL bukan hal yang pengen kamu punya, itulah celah persis yang dibangun sama stack developer Thunderbit. Mesin AI yang sama di balik 100.000+ pengguna ekstensi kami, diekspos dalam tiga cara buat kerjaan teknis—dengan infrastruktur tetep di sisi kami.
- Open API (REST).
POST /distillngubah halaman jadi Markdown bersih, siap LLM;POST /extractngembaliin data terstruktur terhadap Skema JSON yang kamu definisiin. Rendering JS, penanganan anti-bot, dan konten dinamis ditangani di sisi server—enggak ada container browser buat kamu jalanin. FlagrenderMode(none/basic/full) ngontrol seberapa keras dia render, dan endpoint batch nangani sampai 100 URL buat distill. - Server MCP. Server Model Context Protocol resmi, jadi agen AI di dalam Claude atau Cursor bisa ngelakuin scraping di tengah tugas:
thunderbit_suggest_fieldsbuat ngerencanain ekstraksi (gratis),thunderbit_distillbuat Markdown,thunderbit_extractbuat data terstruktur. Agen mutusin kapan narik data tanpa ninggalin lingkungannya. - CLI.
npx -y @thunderbit/thunderbit-clingejalanin scrape dari terminal, script, CI, atau cron—tanpa browser, tanpa stack buat diawasin. Salurin langsung ke alat lain:thunderbit distill "$URL" -f markdown | claude -p "summarise".
Kontras sama Firecrawl yang di-hosting sendiri itu jelas banget. Firecrawl yang di-hosting sendiri ngasih kamu kontrol penuh dan kepemilikan operasional penuh: enam container, bobot setup, ketentuan AGPL, dan tanpa Fire-engine buat anti-blokir. API/MCP/CLI Thunderbit nuker kontrol itu dengan mesin yang di-hosting yang ngembaliin JSON terstruktur yang cocok sama skema—bukan cuma Markdown mentah—dengan container, lapisan anti-bot, dan kewajiban copyleft dihilangin dari kamu. Alat yang beda buat selera infrastruktur yang beda.
Ini dia trade-off dalam satu tampilan:
| Pertimbangan | Firecrawl yang di-hosting sendiri | Tumpukan pengembang Thunderbit (API · MCP · CLI) |
|---|---|---|
| Bentuk penerapan | Layanan yang kamu operasikan (6 kontainer) | API yang di-hosting yang kamu panggil |
| Untuk mulai berjalan | docker compose ngejalanin stack 6 layanan | Kunci API, terus permintaan |
| Rendering JS | playwright-service yang dibundel (kamu ngejalaninnya) | Sisi server, flag renderMode |
| Output terstruktur | Butuh kunci LLM (/extract, json) | POST /extract dengan Skema JSON |
| Lapisan anti-bot | Enggak ada yang di-hosting sendiri (Fire-engine cuma cloud) | Ditangani di sisi server |
| Lisensi | AGPL-3.0 (copyleft penggunaan jaringan) | API komersial, enggak ada copyleft pada kode kamu |
| Terbaik ketika | Kamu pengen kontrol penuh dan bakal ngejalanin infrastruktur | Kamu pengen Markdown/data terstruktur tanpa operasi |
Enggak ada yang secara universal "lebih baik." Kalo ngejalanin platform adalah intinya buat kamu—kontrol data penuh, enggak ada ketergantungan eksternal, dan AGPL sesuai sama situasi kamu—Firecrawl yang di-hosting sendiri adalah pilihan yang mampu dan aktif dipelihara. Kalo kamu lebih suka ngelakuin panggilan API dan ngelewatin kehidupan enam container, itulah tawaran buat stack Thunderbit.
Siapa yang Seharusnya Meng-hosting Sendiri Firecrawl
Singkirin hype dan gambarannya cukup jelas buat diurutin berdasarkan kebutuhan.
Hosting sendiri Firecrawl kalo kamu pengen kontrol penuh atas infrastruktur scraping kamu, kamu nyaman ngoperasiin Redis / RabbitMQ / Postgres / FoundationDB dalam produksi, kebutuhan rendering kamu membenarkan container playwright-service, dan AGPL-3.0 berfungsi buat cara kamu menerapkan. Kemampuan intinya nyata: Saya dapet Markdown bersih, terstruktur, siap LLM dari halaman statis dan halaman yang di-render JS, dan seluruh stack jalan pada image yang udah jadi.
Cari di tempat lain kalo kamu pengen script lokal cepet (ini adalah setup terberat dalam basis, titik), kamu butuh anti-blokir kelas cloud tanpa ngoperasiinnya sendiri (yang di-hosting sendiri enggak punya Fire-engine), atau klausul penggunaan jaringan AGPL bertabrakan sama rencana komersial kamu. Buat kasus "Saya cuma butuh Markdown atau data terstruktur dari URL, tanpa operasi," API yang di-hosting kayak /distill dan /extract Thunderbit nyakup hal yang sama tanpa container.
Bacaan awal saya: inti yang kuat, komitmen operasional yang berat, dan lisensi yang harus kamu selesaiin sebelum bikin secara komersial. Ini dapet tempatnya buat tim yang pengen punya seluruh pipeline—dan itu minta banyak dari orang lain. Saya bakal nengok lagi ini setelah saya ngejalanin /v1/crawl, pakai /extract dengan kunci LLM, dan validasi build dari sumber pada daemon non-colima; itu adalah pertanyaan terbuka antara ini dan putusan akhir.
Coba Thunderbit untuk Ekstraksi Data Web Get Started Free
FAQ
Apakah Firecrawl yang di-hosting sendiri sama dengan versi cloud?
Enggak. Yang di-hosting sendiri ngasih kamu mesin scrape-to-Markdown inti dan rendering JavaScript via playwright-service yang dibundel, tapi enggak termasuk Fire-engine, lapisan anti-blokir milik produk cloud. Fitur AI kayak endpoint /extract dan output json juga butuh kunci LLM kamu sendiri (OpenAI atau Ollama). Dalam ulasan ini saya cuma nguji stack yang di-hosting sendiri; API cloud ada di luar cakupan.
Berapa banyak container yang sebenernya dibutuhkan Firecrawl yang di-hosting sendiri? Enam: api, playwright-service, redis, rabbitmq, nuq-postgres, dan foundationdb. Ini adalah stack layanan lengkap, bukan binary tunggal—itulah kenapa ini adalah setup terberat dari semua alat di riset ini. Rencanakan overhead operasional ngejalanin infrastruktur message broker, cache, dan database, bukan cuma script.
Bisakah Firecrawl nangani halaman yang banyak pakai JavaScript saat di-hosting sendiri? Ya, dalam pengujian saya. playwright-service yang dibundel render halaman di mesin browser sungguhan sebelum ekstraksi. Saya ngonfirmasi ini di quotes.toscrape.com/js/, di mana kutipan Einstein—konten yang cuma ada setelah JavaScript jalan—muncul di Markdown yang dikembaliin. Kemampuan rendering itulah kenapa salah satu dari enam container adalah headless browser.
Apakah lisensi AGPL-3.0 memengaruhi penggunaan komersial? Bisa, dan kamu harus memperlakukannya sebagai pertanyaan tingkat pertama. AGPL-3.0 adalah copyleft yang kuat dengan klausul penggunaan jaringan, yang berarti nawarin fungsionalitas software ke pengguna via jaringan bisa bawa kewajiban ketersediaan sumber—bahkan kalo kamu enggak pernah ngedistribusiin binary. Kalo kamu berencana buat bikin produk komersial pada instance yang di-hosting sendiri, ngobrol sama siapa pun yang nangani lisensi di perusahaan kamu sebelum kamu berkomitmen. Ulasan ini nandain lisensi; ini bukan nasihat hukum.
Apa perbedaan antara Firecrawl dan alat pengembang Thunderbit?
Firecrawl yang di-hosting sendiri adalah layanan yang kamu operasikan—enam container yang kamu jalanin sendiri, dengan ketentuan AGPL-3.0 dan tanpa lapisan anti-blokir bawaan. Stack developer Thunderbit (Open API, server MCP, CLI) adalah mesin yang di-hosting yang kamu panggil: POST /distill buat Markdown, POST /extract buat data terstruktur Skema JSON, dengan rendering JS dan penanganan anti-bot di sisi server dan tanpa kewajiban copyleft pada kode kamu sendiri. Firecrawl cocok buat tim yang pengen kontrol infrastruktur penuh; Thunderbit cocok buat mereka yang pengen output tanpa beban operasional.
