Çoğu kişi Firecrawl için scraping kütüphaneleriyle aynı sepete koyar — hani şu pip install yap, bir script yaz, iş tamam kafası. Bu bakış açısı yanlış; ve ilk komutu yazmadan önce bunun farkını bilmek önemli. Firecrawl self-hosted, içeri aktarıp kullandığınız bir kütüphane değil; sizin işlettiğiniz bir servistir. Kurmak ise birbiriyle konuşan altı Docker konteynerini çalıştırmak demektir.
Self-hosted stack’i bir Mac üzerinde (arm64, Docker colima üzerinden) çalıştırdım; elimde herhangi bir cloud key yoktu. /v1/scrape endpoint’ini scraping dostu birkaç demo siteye yönlendirdim ve geriye ne döndüğüne baktım. Kısa özet: temel vaat karşılandı — sayfa içeri giriyor, temiz ve LLM uyumlu Markdown çıkıyor — fakat bugüne kadar bu araştırma setinde denediğim araçlar içinde kurulum tarafı en ağır olan buydu. Bu yazı nihai hüküm değil, geçici bir değerlendirme; neyi test edip neyi test etmediğimi net biçimde belirteceğim.
Firecrawl Bir Kütüphane Değil, Servistir
Önce zihindeki modeli düzeltmek gerekiyor. Geliştiricilerin en sık kullandığı scraping araçları genelde kütüphanelerdir: bir bağımlılık eklersiniz, bir fonksiyon çağırırsınız, HTML ya da ayrıştırılmış veriyi kendi uygulama sürecinizin içinde geri alırsınız. Firecrawl self-hosted ise bambaşka bir yapı. Kendi API’si olan çalışan bir platformdur; onunla HTTP üzerinden konuşursunuz.
Resmî tanımı, "web’i büyük ölçekte aramak, scrape etmek ve etkileşim kurmak için API" şeklindedir; ürünün yapısı da tam olarak budur — sayfa içeri girer, temiz Markdown ya da yapılandırılmış veri çıkar. Self-host ettiğinizde Firecrawl’a bağlanmış olmazsınız. Bir docker compose stack’i ayağa kaldırır ve bir endpoint’e istek atarsınız; tıpkı şirket içi bir microservice’e gider gibi.
Çalıştırdığım stack altı servisten oluşuyordu:
- api — gerçekten çağrı yaptığınız HTTP yüzeyi
- playwright-service — JavaScript render etmek için headless tarayıcı
- redis — kuyruk ve önbellek
- rabbitmq — mesaj aracısı
- nuq-postgres — iş durumları için bir Postgres varyantı
- foundationdb — dağıtık key-value depolama
Bu, yardımcı bir script değil; gerçek bir backend. Redis, RabbitMQ, Postgres ve FoundationDB’nin her biri başlı başına kurumsal seviyede altyapılar. Bunun karşılığında Firecrawl, scraping’in zahmetli kısımlarını — kuyruklama, render etme, yeniden deneme — tek bir API çağrısının arkasında yönetiyor. Bedeli ise şu: artık o altı konteynerin işletim sorumluluğu sizde. Bu dengeyi akılda tutun; bu incelemenin omurgası tam olarak bu.
Referans olması için belirteyim: firecrawl-py 4.32.0 ve firecrawl-js 4.30.0 SDK’larıyla test yaptım, ayrıca resmi önceden derlenmiş ghcr.io/firecrawl/firecrawl:latest imajını 2026-07-09 tarihinde çektim. O tarihte repo yaklaşık 148k yıldız seviyesindeydi (bunu kalite puanı değil, metadata olarak okuyun); AGPL-3.0 lisansı altında dağıtılıyor — ve birazdan geri döneceğim üzere bu detay ticari kullanım hesabını ciddi biçimde değiştiriyor.
Temel Test: Bir Sayfa Temiz Markdown’a Dönüşüyor mu?
Firecrawl’ın var olma sebebi, bir web sayfasını bir LLM’in gerçekten okuyabileceği Markdown’a çevirmektir. İlk baktığım şey de bu oldu.
/v1/scrape endpoint’ini books.toscrape.com adresine yönlendirdim; burası scraping pratiği için bilerek oluşturulmuş statik bir katalog. Sonuç: sayfa başlığı All products | Books to Scrape doğru şekilde ayrıştırılmış halde, 9.222 karakter temiz ve LLM uyumlu Markdown. Ham HTML’nin string içine basıldığı bir çıktı değil — başlıklar, bağlantılar ve görsel referansları korunmuş, yapılandırılmış Markdown. Doğrudan bir retrieval pipeline’a koyabileceğiniz ya da ikinci bir temizleme aşaması olmadan modele verebileceğiniz türden bir çıktı.
Bu, Firecrawl’ın en güçlü tarafı ve self-hosted sürüm bunu sorunsuz sundu. İşiniz "bu sayfanın okunabilir özünü Markdown olarak ver" ise, statik bir sayfa beklediğiniz gibi geri geldi. Bu gerçekten faydalı bir temel yetenek; aracın neden bu kadar ilgi gördüğünü de açıklıyor.
Kapsam konusunda net olayım: burada yalnızca tek sayfalık /v1/scrape akışını denedim. Tüm siteyi tarayan çok sayfalı /v1/crawl özelliğini test etmedim. Bu ayrı bir yetenek ve kendi hata senaryoları var; çalıştırmadığım bir şey için iyi çalışıyor demeyeceğim.
JavaScript Sayfaları: Paketli Tarayıcı Kendi Konteynerini Hak Ediyor
Statik sayfa kolay senaryo. Her scraper için asıl zor soru şudur: içerik yalnızca JavaScript çalıştıktan sonra görünüyorsa ne olur? Modern web’de durum çoğu zaman budur.
İşte burada playwright-service konteyneri gereksiz yük olmaktan çıkıp asıl noktaya dönüşüyor. Scraper’ı quotes.toscrape.com/js/ adresine, alıntıların istemci tarafında render edildiği demo sürümüne yönlendirdim. Firecrawl yalnızca ham HTML çekseydi alıntılar görünmezdi — çünkü sayfanın script’i çalışmadan ortada yoklar.
Scrape sonucu 1.574 karakter Markdown olarak döndü ve Einstein alıntısı içinde vardı. Bu alıntı JavaScript sonrası içeriktir: onun görünmesi, playwright-service’in metni çekmeden önce sayfayı gerçekten bir tarayıcı motorunda render ettiğinin kanıtı. Yani boş, render edilmemiş kabuğu almak yerine gerçek sayfa işlenmişti.
Demek ki altı konteynerin biri headless tarayıcı ve tam da bu iş için var. Ağır mimariyi meşrulaştıran somut neden bu: yalnızca konteyner çalıştırıyor olmuyorsunuz, JavaScript ağırlıklı sayfaları kendi tarayıcı otomasyonunuzu kurmadan render edebilme kabiliyeti satın alıyorsunuz. Gerçek dünyadaki pek çok hedef için fark, kullanılabilir çıktı ile boş div’ler arasındaki fark oluyor.
Hedef Kötüyse Ne Olur: Yapılandırılmış Hata, Çökme Yok
Scraper’lar yaşamlarının şaşırtıcı derecede büyük bir kısmını bozuk şeylere yönelmiş halde geçirir: ölü host’lar, yanlış yazılmış URL’ler, bağlantıyı asan sunucular. Bir aracın nasıl başarısız olduğu, nasıl başarılı olduğuna dair ipucu verir.
API’ye bilerek geçersiz bir host verdim. Sonuç olarak yapılandırılmış bir HTTP 500 döndü ve çalışmaya devam etti — istemciye stack trace saçılmadı, konteyner devrilmedi, süreç kilitlenmedi. Hata, çağıran tarafın dallandırıp yönetebileceği temiz bir yanıt olarak geldi.
Bu, bir pipeline içinde kullanmak istediğiniz bir araç için olması gereken sıkıcı ama doğru davranış. Kötü bir hedefte panikleyen scraper, otomasyona uygun değildir. Bu araç ise yakalanıp işlenebilecek bir hata döndürdü. Yalnızca tek bir hata senaryosu test ettim; dolayısıyla bunu "attığım tek hatayı doğru yönetti" diye okuyun, kapsamlı bir dayanıklılık testi olarak değil — ama tek veri noktası da doğru sonuçtu.
Kurulum Gerçeği: Bu Araştırma Setindeki En Ağır Adım
Şimdi lansman tweet’inde kimsenin paylaşmadığı kısım. Firecrawl self-hosted, abartısız söylüyorum, bu araştırma setinde ayağa kaldırması en zahmetli araçtı — ve ben epey sistem kurmuşumdur.
Altı konteyner zaten temel maliyet. Ama kurulum sırasında iki aksaklıkla da karşılaştım; burada kimin hatası olduğunu açıkça söylemek isterim — ortaya çıktı ki Firecrawl’ın değil.
Birinci aksaklık: kaynak koddan build. İmajları kaynaktan derlemek, colima VM içinde containerd snapshotter hatasıyla başarısız oldu. Bu, build ile colima’nın depolama katmanı arasındaki bilinen, zaman zaman hata veren bir etkileşim — yani Firecrawl’da değil, benim ortamımdaki altyapı kaynaklı bir aksaklık. Compose dosyası alternatif olarak resmî önceden derlenmiş ghcr.io/firecrawl/* imajlarını kullanmayı belgeliyor. Onlara geçince stack tertemiz ayağa kalktı. Standart bir Docker daemon kullanıyor olsaydınız bunu hiç görmeyebilirdiniz; bunu çevresel bir not olarak işaretliyorum ve katkı sağlayan build’in temiz bir daemon üzerinde doğrulanması eksik listemde.
İkinci aksaklık: SSRF koruması. İlk scrape denemelerim Firecrawl’ın özel IP / SSRF koruması tarafından engellendi. Neden? colima’nın ağ yapılandırması, public hostname’leri 198.18.x.x adreslerine eşliyor; bu aralık Firecrawl tarafından doğru biçimde özel kabul ediliyor. Yani güvenlik katmanı görevini yaptı ve iç ağ gibi görünen bir hedefi çekmeyi reddetti. Yalnızca yerel test için bunu aşmak adına ALLOW_LOCAL_WEBHOOKS=true ayarladım.
Bu bayrak prod ortamına kopyalanırsa sorun çıkarır; o yüzden tam olarak ne olduğuna dikkat edin: SSRF koruması bir engel değil, bir özelliktir. Bir scraping servisini kandırıp iç ağınıza isabet ettirilmesini engeller. Ben bunu, colima’nın DNS garipliği yüzünden meşru public hedeflerim VM içinde özelmiş gibi göründüğü için devre dışı bıraktım. Gerçek bir kurulumda SSRF korumasını kapatmayın. Bu incelemeden tek bir operasyon notu alacaksanız, o bu olsun.
Dürüst olmak gerekirse her iki aksaklık da laptop üzerinde colima ile Docker çalıştırmanın yan ürünüydü — yazılımdaki bir kusur değildi. Öte yandan kurulumun ağırlığı gerçek ve bu ağırlık Firecrawl’ın tasarımının bir parçası. Bu, hızlı bir local script istediğinizde seçilecek araç değil; render kabiliyetli bir scraping servisine ihtiyaç duyduğunuzda ve bunun için altyapı işletmeyi kabul ettiğinizde ayağa kaldıracağınız araç.
Neleri Test Etmedim ve Neler Yok
Şimdi hem test etmediğim hem de aracın vermediği şeyler.
Self-hosted sürümde Fire-engine yok. Firecrawl’ın cloud ürünü, bot engellerini aşmak için kendi özel anti-block katmanı olan Fire-engine ile geliyor. Projenin kendi SELF_HOST.md dosyasına göre self-hosted örneklerde bu özellik yok. Yani self-hosted Firecrawl’ın agresif anti-bot sistemleri kutudan çıktığı gibi aşacağını düşünüyorsanız beklentiyi düzeltin — bu yetenek cloud katmanında yer alıyor ve benim çalıştırdığım kuruluma dahil değildi.
Cloud API burada test edilmedi. Elimde cloud key yoktu; bu yüzden yukarıdakilerin hepsi yalnızca self-hosted stack’e ait. Yönetilen cloud servisi — Fire-engine, barındırılan ölçekleme ve AI özellikleriyle — farklı bir ürün; dışarıdan bakarak performansı hakkında yorum yapmayacağım. Cloud tarafına dair herhangi bir iddiayı bu incelemenin kapsamı dışında kabul edin.
AI özellikleri için key gerekiyor. json yapılandırılmış çıktı formatı ve /extract endpoint’i bir LLM’e dayanıyor; yani OpenAI key’i getirmek ya da Ollama bağlamak gerekiyor. Bu yolları kullanmadım; dolayısıyla /extract ve yapılandırılmış json çıktısı da test edilmemişler arasında.
Proxy desteği bir nottur, başlık değil. Firecrawl proxy yapılandırmasını destekliyor; fakat bunu bilerek dipnotta bırakıyorum — kullanabileceğiniz bir ayar, aracı seçme sebebi değil. Ayrıca self-hosted sürüm, cloud’daki anti-block katmanına yine de sahip değil.
AGPL-3.0 gerçek bir uyum kararıdır. Buna ayrı bir vurgu gerekiyor.
Lisans: Yayına Almadan Önce AGPL-3.0’ı Okuyun
Firecrawl, AGPL-3.0 lisansı altında sunuluyor. Bu, README’nin sonunda geçiştirilecek bir satır değil — ağ üzerinden kullanım maddesi olan güçlü copyleft’tir ve self-hosted bir örnek üzerine ticari bir ürün kurup kuramayacağınızı doğrudan etkileyebilir.
Kısaca: standart GPL yükümlülükleri dağıtımda devreye girer. AGPL ise bir adım ileri gider — network-use hükmü, yazılımın işlevini kullanıcılara ağ üzerinden sunmayı da kaynak paylaşımı yükümlülüğü doğurabilecek kullanım türüne sokabilir. Eğer self-hosted Firecrawl’ı müşterilerinizin internet üzerinden eriştiği bir servisin içine gömüyorsanız, bu madde doğrudan konunun merkezindedir; "binary dağıtmadık" yaklaşımı sandığınız kaçış yolu olmayabilir.
Ben avukat değilim; lisans yorumu tam olarak nasıl kurduğunuza göre değişir. Ama ticari bir öneri yaparken AGPL-3.0 dipnot değil, öncelikli bir husustur. Üzerine inşa etmeden önce şirketinizde lisans işlerinden sorumlu kişiyle konuşun. Bunu vurgulamam Firecrawl’a bir eleştiri değil — birçok mükemmel araç AGPL kullanıyor — sadece erken aşamada masada olması gereken bir gerçek.
Thunderbit’in Geliştirici Stack’i Bu Resimde Nerede Duruyor
Web Verisi Çekmek İçin Thunderbit’i Deneyin
Asıl hedefiniz "sayfa → LLM uyumlu Markdown" ya da "sayfa → yapılandırılmış veri" ise; altı konteynerlik operasyon maliyeti ve AGPL sorumluluğunu da üstlenmek istemiyorsanız, Thunderbit'in geliştirici stack’i tam bu boşluğu doldurmak için tasarlandı. 100.000+ uzantı kullanıcımızın arkasındaki aynı AI motoru, teknik işler için üç farklı şekilde sunuluyor — altyapı tarafı ise bizim kontrolümüzde kalıyor.
- Open API (REST).
POST /distillbir sayfayı temiz, LLM uyumlu Markdown’a çevirir;POST /extractise tanımladığınız bir JSON Schema üzerinden yapılandırılmış veri döner. JS rendering, anti-bot yönetimi ve dinamik içerik sunucu tarafında ele alınır — sizin çalıştırmanız gereken bir tarayıcı konteyneri yoktur.renderModebayrağı (none/basic/full) render yoğunluğunu ayarlamanızı sağlar; toplu endpoint’ler ise distill için 100 URL’ye kadar destek verir. - MCP server. Resmî bir Model Context Protocol sunucusu; böylece Claude veya Cursor içindeki bir AI ajanı işin ortasında scrape yapabilir: çıkarım planlamak için
thunderbit_suggest_fields(ücretsiz), Markdown içinthunderbit_distill, yapılandırılmış veri içinthunderbit_extract. Ajan, ortamından çıkmadan veriyi ne zaman çekeceğine kendisi karar verir. - CLI.
npx -y @thunderbit/thunderbit-cli, terminalden, script’lerden, CI’den veya cron’dan scrape çalıştırır — tarayıcı yok, bakımı gereken stack yok. Sonucu başka araçlara doğrudan aktarabilirsiniz:thunderbit distill "$URL" -f markdown | claude -p "özetle".
Self-hosted Firecrawl ile farkı net: Firecrawl self-hosted size tam kontrol ve tam operasyonel sahiplik verir; altı konteyner, kurulum ağırlığı, AGPL şartları ve Fire-engine olmadan anti-block katmanı yok. Thunderbit’in API/MCP/CLI yaklaşımı ise bu kontrolün yerine, size bakım yükü bindirmeden şemaya uygun yapılandırılmış JSON döndüren barındırılmış bir motor sunar — yalnızca ham Markdown değil. Farklı altyapı iştahları için farklı araçlar.
İşte farkın tek bakışta özeti:
| Değerlendirme | Firecrawl self-hosted | Thunderbit dev stack (API · MCP · CLI) |
|---|---|---|
| Kurulum biçimi | Sizin işlettiğiniz servis (6 konteyner) | Çağrı yaptığınız hosted API |
| Çalıştırmak için | 6 servislik docker compose ayağa kaldırın | API key alın, sonra istek gönderin |
| JS rendering | Paketli playwright-service (siz çalıştırırsınız) | Sunucu tarafında, renderMode bayrağı |
| Yapılandırılmış çıktı | LLM key gerekir (/extract, json) | JSON Schema ile POST /extract |
| Anti-bot katmanı | Self-hosted’da yok (Fire-engine yalnızca cloud’da) | Sunucu tarafında ele alınır |
| Lisans | AGPL-3.0 (network-use copyleft) | Ticari API, kodunuz üzerinde copyleft yok |
| En uygun olduğu durum | Tam kontrol istiyorsunuz ve altyapı çalıştıracaksınız | Operasyon yükü olmadan Markdown/yapılandırılmış veri istiyorsunuz |
Hiçbiri evrensel olarak "daha iyi" değil. Eğer platformu işletmek zaten sizin işinizse — tam veri kontrolü, dışa bağımlılık istememek ve AGPL’nin durumunuza uyması — self-hosted Firecrawl yetkin ve aktif şekilde bakımı yapılan bir seçenek. Yok ben sadece bir API çağırayım, altı konteyner hayatına girmeyeyim diyorsanız, Thunderbit stack’i tam bu vaadi sunuyor.
Firecrawl’ı Kimler Gerçekten Self-Host Etmeli?
Abartıyı bir kenara bırakınca tablo ihtiyaca göre ayrıştırılacak kadar netleşiyor.
Firecrawl self-host etmelisiniz eğer scraping altyapınız üzerinde tam kontrol istiyorsanız, Redis / RabbitMQ / Postgres / FoundationDB’yi production’da işletmek size uygunsa, render ihtiyaçlarınız playwright-service konteynerini anlamlı kılıyorsa ve AGPL-3.0 kullanım modelinize uyuyorsa. Temel kabiliyet gerçek: hem statik hem de JS render edilmiş sayfadan temiz, yapılandırılmış, LLM uyumlu Markdown aldım; ayrıca stack’in tamamı önceden derlenmiş imajlarla çalıştı.
Başka yere bakmalısınız eğer hızlı bir local script istiyorsanız (dürüst olmak gerekirse bu araştırma setindeki en ağır kurulum bu), cloud düzeyinde anti-block’a kendiniz işletmeden ihtiyaç duyuyorsanız (self-hosted’da Fire-engine yok) ya da AGPL’nin network-use hükmü ticari planlarınıza takılıyorsa. "Ben sadece bir URL’den Markdown ya da yapılandırılmış veri istiyorum, operasyon yükü olmasın" diyorsanız, Thunderbit’in /distill ve /extract gibi hosted API’leri aynı sonucu konteynerlere ihtiyaç duymadan sağlar.
Benim geçici değerlendirmem: güçlü bir çekirdek, ağır bir operasyonel yük ve ticari kullanım öncesi netleştirmeniz gereken bir lisans. Tüm hattı sahiplenmek isteyen ekipler için yerini hak ediyor — ama geri kalan herkesten de epey şey istiyor. /v1/crawl’ı çalıştırıp, /extract’i bir LLM key ile deneyip, kaynak koddan build’i colima dışı bir daemon üzerinde doğruladığımda bu değerlendirmeye geri döneceğim; nihai kararla bu yazı arasında hâlâ açık olan sorular bunlar.
Web Verisi Çekmek İçin Thunderbit’i Deneyin Get Started Free
Sıkça Sorulan Sorular
Self-hosted Firecrawl, cloud sürümüyle aynı mı?
Hayır. Self-hosted sürüm size temel scrape-to-Markdown motorunu ve paketli playwright-service üzerinden JavaScript rendering’i verir; ancak cloud ürünündeki özel anti-block katmanı Fire-engine’i içermez. /extract endpoint’i ve json çıktısı gibi AI özellikleri için de kendi LLM key’inizi getirmeniz gerekir (OpenAI veya Ollama). Bu incelemede yalnızca self-hosted stack’i test ettim; cloud API kapsam dışıydı.
Self-hosted Firecrawl gerçekte kaç konteyner gerektiriyor? Altı tane: api, playwright-service, redis, rabbitmq, nuq-postgres ve foundationdb. Bu, tek bir binary değil tam bir servis stack’i — dolayısıyla bu araştırma setindeki en ağır kurulum olmasının sebebi de bu. Sadece bir script değil, mesaj aracısı, önbellek ve veritabanı altyapısını işletmenin operasyonel yükünü de hesaba katın.
Firecrawl, self-hosted durumda JavaScript ağırlıklı sayfaları işleyebilir mi? Evet, testimde işledi. Paketli playwright-service, extraction öncesinde sayfaları gerçek bir tarayıcı motorunda render ediyor. Bunu quotes.toscrape.com/js/ üzerinde doğruladım; sadece JavaScript çalıştıktan sonra var olan Einstein alıntısı dönen Markdown içinde yer aldı. Bu render kabiliyeti, altı konteynerden birinin neden headless tarayıcı olduğunu açıklıyor.
AGPL-3.0 lisansı ticari kullanımı etkiler mi? Evet, etkileyebilir; bunu birincil soru olarak ele almalısınız. AGPL-3.0, network-use maddesi olan güçlü copyleft’tir; bu da yazılımın işlevini kullanıcılara ağ üzerinden sunmanın, binary dağıtmıyor olsanız bile, kaynak paylaşımı yükümlülüğü doğurabileceği anlamına gelir. Self-hosted bir örnek üzerinde ticari ürün geliştirmeyi planlıyorsanız, işe başlamadan önce şirketinizde lisans işlerinden sorumlu kişiyle konuşun. Bu inceleme lisansı işaret eder; hukuki tavsiye vermez.
Firecrawl ile Thunderbit’in geliştirici araçları arasındaki fark nedir?
Firecrawl self-hosted sizin işlettiğiniz bir servistir — altı konteyneri kendiniz çalıştırırsınız; AGPL-3.0 şartları vardır ve gömülü anti-block katmanı yoktur. Thunderbit’in geliştirici stack’i (Open API, MCP server, CLI) ise çağırdığınız hosted bir motordur: Markdown için POST /distill, JSON Schema yapılandırılmış veri için POST /extract; JS rendering ve anti-bot yönetimi sunucu tarafında ele alınır ve kendi kodunuz üzerinde copyleft yükümlülüğü yoktur. Firecrawl tüm altyapıyı kontrol etmek isteyen ekipler için uygundur; Thunderbit ise operasyon yükü olmadan çıktıyı isteyenler içindir.
