Většina lidí si Firecrawl řadí do stejné škatulky jako scrapingové knihovny — tedy do světa typu „pip install, napíšu skript a hotovo“. Jenže tohle chápání je chybné a ten rozdíl je důležitý ještě dřív, než napíšete jediný příkaz. Firecrawl self-hosted není knihovna, kterou si importujete; je to služba, kterou provozujete, a její zprovoznění znamená spustit šest Docker kontejnerů, které mezi sebou komunikují.
Self-hosted stack jsem testoval na Macu (arm64, Docker přes colima) bez cloudového klíče, nasměroval jsem jeho endpoint /v1/scrape na pár ukázkových webů vhodných pro scraping a sledoval, co vrací. Stručně řečeno: hlavní slib obstál — stránka se načetla a ven vylezl čistý LLM-ready Markdown — ale nastavení bylo nejnáročnější ze všech nástrojů, které jsem v téhle výzkumné sadě testoval. Berte to jako předběžný pohled, ne finální verdikt; jasně oddělím, co jsem testoval a co ne.
Firecrawl je služba, ne knihovna
Nejdřív je potřeba srovnat mentální model. Scrapingové nástroje, po kterých vývojáři sahají nejčastěji, jsou knihovny: přidáte závislost, zavoláte funkci a HTML nebo zpracovaná data dostanete zpět ve svém vlastním procesu. Firecrawl self-hosted je ale jiný živočich. Je to běžící platforma s vlastním API a komunikuje se s ní přes HTTP.
Oficiální popis zní „API pro vyhledávání, scraping a interakci s webem ve velkém měřítku“ a produkt přesně tak působí — vstupem je stránka, výstupem čistý Markdown nebo strukturovaná data. Při self-hostingu Firecrawl nepřipojujete jako knihovnu. Zvedáte docker compose stack a voláte endpoint stejně, jako byste oslovovali interní microservice.
Stack, který jsem spustil, měl šest služeb:
- api — HTTP rozhraní, které skutečně voláte
- playwright-service — headless prohlížeč pro renderování JavaScriptu
- redis — fronta a cache
- rabbitmq — message broker
- nuq-postgres — varianta Postgresu pro stav úloh
- foundationdb — distribuované key-value úložiště
Tohle je plnohodnotný backend, ne pomocný skript. Redis, RabbitMQ, Postgres i FoundationDB jsou samy o sobě infrastruktura průmyslové úrovně. Odměnou je, že Firecrawl řeší těžké části scrapingu — frontování úloh, renderování, opakování pokusů — za jediným API voláním. Cena je, že tyhle čtyři až šest komponent teď provozujete vy. Tu výměnu mějte neustále na paměti; je to červená nit celé recenze.
Pro úplnost: testoval jsem proti SDK firecrawl-py 4.32.0 a firecrawl-js 4.30.0 a stáhl jsem oficiální předpřipravený image ghcr.io/firecrawl/firecrawl:latest dne 2026-07-09. Repo mělo k tomu datu zhruba 148 tisíc hvězd (berte to jako metadata, ne jako hodnocení kvality) a používá licenci AGPL-3.0 — k tomu se ještě vrátím, protože to mění ekonomiku komerčního použití.
Základní test: ze stránky se stane čistý Markdown
Celý důvod, proč Firecrawl existuje, je převést webovou stránku do Markdownu, který dokáže LLM skutečně číst. To je tedy první věc, kterou jsem ověřil.
Endpoint /v1/scrape jsem nasměroval na books.toscrape.com, statický katalog vytvořený přímo pro trénink scrapingu. Výsledek: 9 222 znaků čistého Markdownu připraveného pro LLM a titulek stránky All products | Books to Scrape byl rozpoznán správně. Žádné syrové HTML nacpané do stringu — ale strukturovaný Markdown se záhlavími, odkazy i odkazy na obrázky zachovanými na svém místě. Přesně ten typ výstupu, který můžete rovnou poslat do retrieval pipeline nebo modelu bez dalšího čištění.
Tohle je hlavní síla Firecrawl a self-hosted varianta ji zvládla bez problémů. Pokud je vaším úkolem „dej mi čitelnou podstatu téhle stránky v Markdownu“, statická stránka se vrátila přesně podle očekávání. A to je opravdu užitečný základní stavební kámen, právě proto má tenhle nástroj takové jméno.
Je fér být přesný v rozsahu testu: vyzkoušel jsem pouze cestu /v1/scrape pro jednu stránku. Netestoval jsem /v1/crawl, tedy vícestránkový crawler, který prochází celý web. To je samostatná funkcionalita s vlastními režimy selhání, a nebudu tvrdit, že funguje, když jsem ji nespustil.
Stránky s JavaScriptem: přibalený prohlížeč si svoje místo zaslouží
Statická stránka je ta snadná varianta. Těžší otázka pro jakýkoli scraper zní: co se stane, když se obsah objeví až po spuštění JavaScriptu — což je na moderním webu většinou ten případ?
Tady přestává být container playwright-service přítěží a začíná být smyslem celé architektury. Nasměroval jsem scraper na quotes.toscrape.com/js/, tedy verzi demo webu, která citáty vykresluje až na straně klienta. Kdyby Firecrawl jen stáhl surové HTML, citáty by tam vůbec nebyly — existují až poté, co prohlížeč spustí skript stránky.
Scrape vrátil 1 574 znaků Markdownu a byl v něm i Einsteinův citát. Ten citát je obsah vzniklý až po vykreslení JavaScriptem; jeho přítomnost potvrzuje, že playwright-service stránku skutečně vykreslil v reálném engine prohlížeče, místo aby jen vzal prázdný shell před renderem.
Jeden ze šesti kontejnerů je tedy headless prohlížeč a dělá přesně to, proč byste si ho pořídili. Tohle je konkrétní obhajoba těžší architektury: neplatíte jen za kontejnery, ale za schopnost vykreslit JS-heavy stránky bez toho, abyste si museli sami stavět browser automation. U spousty reálných cílů je to rozdíl mezi použitelným výstupem a prázdnými divy.
Když je cíl špatně: strukturovaná chyba, žádný pád
Scrapery tráví překvapivě hodně času tím, že míří na věci, které nefungují — mrtvé hosty, špatně napsané URL, servery, které se odmlčí. Způsob, jakým nástroj selže, hodně napoví o tom, jak se chová, když funguje.
Do API jsem záměrně poslal neplatný host. Vrátilo to strukturovaný HTTP 500 a pokračovalo to dál — žádný stack trace poslaný klientovi, žádný pád kontejneru, žádný visící proces. Chyba přišla jako čistá odpověď, podle které může volající větev rozhodnout, co dál.
To je přesně to nudné, správné chování, které chcete v pipeline. Scraper, který panikaří při špatném cíli, se nedá spolehlivě automatizovat. Tohle mi vrátilo chybu, kterou lze odchytit a pokračovat dál. Testoval jsem jen jeden chybový scénář, takže to berte jako „na jeden konkrétní fail reagoval správně“, ne jako kompletní audit odolnosti — ale v tom jednom bodě to dopadlo správně.
Realita nastavení: nejtěžší zátěž v celé sadě
A teď část, kterou si nikdo nefotí do launch tweetu. Firecrawl self-hosted bylo bez přehánění nejsložitější nasazení ze všech nástrojů v této výzkumné sadě — a že jsem jich zprovozňoval opravdu hodně.
Šest kontejnerů je základní cena vstupu. Navíc jsem ale cestou narazil na dva zádrhely a chci přesně říct, čí byly. Nakonec ne Firecrawlovy.
Zádrhel jedna: build ze zdrojáků. Sestavení image ze zdrojových kódů v mém colima VM selhalo na chybě containerd snapshotteru. Jde o známou občasnou nekompatibilitu mezi buildem a úložištěm colimy — problém infrastruktury v mém prostředí, ne bug ve Firecrawl. Compose soubor dokumentuje alternativu: použít oficiální předpřipravené image ghcr.io/firecrawl/* místo lokálního buildu. Přepnul jsem na ně a celý stack se zvedl bez problémů. Pokud běžíte na standardním Docker daemonu a ne na colimě, možná to vůbec neuvidíte; uvádím to jako environmentální poznámku a ověřit contributor build na čistém daemonu je na mém seznamu nedodělků.
Zádrhel dva: SSRF ochrana. Moje první scrape byly zablokované Firecrawl ochranou proti privátním IP / SSRF. Proč? Síťové mapování colimy převádí veřejné hostname na adresy 198.18.x.x, které spadají do rezervovaného rozsahu, jenž Firecrawl správně vyhodnocuje jako privátní — takže jeho bezpečnostní vrstva dělala přesně to, co má, a odmítla načíst něco, co vypadalo jako interní cíl. Pro lokální testování jsem to obešel nastavením ALLOW_LOCAL_WEBHOOKS=true.
Tenhle příznak se někde zkopíruje do produkce a pak způsobí incident, takže si ujasněme, co to je: SSRF ochrana je funkce, ne překážka. Právě ona brání tomu, aby byl scrapingový služba zneužitá k útoku na vaši interní síť. Vypnul jsem ji proto, že zvláštnost DNS v colimě způsobila, že se mé legitimní veřejné cíle uvnitř VM jevily jako privátní. V reálném nasazení SSRF ochranu nevypínejte. Pokud si z téhle recenze odnesete jedinou provozní poznámku, ať je to tahle.
Oba zádrhely byly popravdě vedlejší efekty toho, že Docker běžel přes colimu na notebooku — nikoli chyba samotného softwaru. Na druhou stranu, váha nastavení je skutečná a je to záměr Firecrawl. Není to nástroj pro rychlý lokální skript; je to nástroj pro situaci, kdy chcete scrapingovou službu schopnou renderovat a jste ochotni kvůli tomu provozovat infrastrukturu.
Co jsem netestoval a co nástroj nedělá
Tady je seznam toho, co jsem nepokryl, a zároveň toho, co Firecrawl samo o sobě nedává.
Self-hosted nemá Fire-engine. Cloudový produkt Firecrawl obsahuje Fire-engine, proprietární anti-block vrstvu pro průchod přes botí obrany. Podle vlastního SELF_HOST.md ji self-hosted instance nedostanou. Takže pokud si představujete, že self-hosted Firecrawl bez dalšího prorazí agresivní anti-bot systémy, je potřeba ten obraz upravit — tahle schopnost patří do cloudové verze a v mém testu nebyla.
Cloudové API tady není otestované. Neměl jsem cloudový klíč, takže vše výše platí jen pro self-hosted stack. Spravovaná cloudová služba — s Fire-engine, hostovaným škálováním a AI funkcemi — je jiný produkt a zvenčí nebudu tvrdit, že znám jeho výkon. Jakákoli cloudová tvrzení tedy berte mimo rámec této recenze.
AI funkce potřebují klíč. Formát strukturovaného výstupu json a endpoint /extract spoléhají na LLM, takže je potřeba vlastní OpenAI klíč nebo napojení na Ollama. Tyto cesty jsem nepouštěl, takže /extract a strukturovaný json výstup jsou také v kolonce netestováno.
Proxy jsou poznámka pod čarou, ne hlavní argument. Firecrawl podporuje proxy konfiguraci, ale uvádím ji jen jako doplněk — je to volba, kterou můžete zapnout, ne důvod, proč si nástroj vybrat. A self-hosted pořád nemá cloudovou anti-block vrstvu.
AGPL-3.0 je skutečné rozhodnutí o souladu s licencí. Tohle si zaslouží samostatnou kapitolu.
Licence: než to nasadíte, přečtěte si AGPL-3.0
Firecrawl je licencovaný pod AGPL-3.0. Není to poznámka do patičky README — je to silný copyleft s klauzulí pro síťové použití a může přímo ovlivnit, zda nad self-hosted instancí vůbec můžete stavět komerční produkt.
Stručně řečeno: u běžné GPL se povinnosti aktivují při distribuci. AGPL jde dál — klauzule o síťovém použití znamená, že už samotné nabídnutí funkcionality uživatelům přes síť může spadat pod režim, který s sebou nese povinnost zpřístupnění zdrojových kódů. Pokud embedujete self-hosted Firecrawl do služby, ke které se zákazníci připojují přes internet, je tahle klauzule naprosto relevantní a „nikdy jsme nerozeslali binárku“ není úniková cesta, jak si mnozí myslí.
Nejsem váš právník a výklad licence závisí na tom, jak přesně ji nasadíte. Ale pro jakékoli komerční doporučení je AGPL-3.0 první liga, ne drobný tisk. Zapojte někoho, kdo ve vaší firmě řeší licence, ještě předtím, než na tom začnete stavět. Tohle není kopnutí do Firecrawl — spousta skvělých nástrojů je AGPL — je to prostě fakt, který musíte mít na stole hned na začátku.
Kde do toho zapadá developerský stack Thunderbit
Vyzkoušet Thunderbit pro extrakci webových dat
Jestli je váš skutečný cíl „stránka → Markdown připravený pro LLM“ nebo „stránka → strukturovaná data“ a šestikontejnerový provozní daň i otázka licence AGPL nejsou něco, co chcete řešit sami, přesně tuhle mezeru má zaplnit developerský stack Thunderbit. Stejný AI engine, který používá naše rozšíření s více než 100 000 uživateli, je pro technickou práci vystaven třemi způsoby — zatímco infrastruktura zůstává na naší straně.
- Open API (REST).
POST /distillpřemění stránku na čistý Markdown připravený pro LLM;POST /extractvrací strukturovaná data podle JSON Schema, které si sami definujete. Renderování JavaScriptu, anti-bot ochrana i dynamický obsah se řeší na straně serveru — vy nemusíte provozovat žádný browser container. ParametrrenderMode(none/basic/full) určuje, jak důkladně se má stránka renderovat, a dávkové endpointy zvládnou až 100 URL pro distill. - MCP server. Oficiální server Model Context Protocol umožňuje AI agentovi v Claude nebo Cursoru scrapovat přímo během úlohy:
thunderbit_suggest_fieldspro návrh extrakce (zdarma),thunderbit_distillpro Markdown,thunderbit_extractpro strukturovaná data. Agent se sám rozhodne, kdy data vytáhnout, a přitom neopustí své prostředí. - CLI.
npx -y @thunderbit/thunderbit-clispouští scrape z terminálu, skriptů, CI nebo cronů — bez prohlížeče a bez stacku, o který byste se museli starat. Výstup můžete rovnou poslat do dalších nástrojů:thunderbit distill "$URL" -f markdown | claude -p "summarise".
Kontrast se self-hosted Firecrawl je jasný. Firecrawl self-hosted vám dává plnou kontrolu i plnou provozní odpovědnost: šest kontejnerů, náročné nastavení, podmínky AGPL a bez Fire-engine pro anti-block. Thunderbit API/MCP/CLI naproti tomu směňuje část kontroly za hostovaný engine, který vrací strukturovaný JSON přesně podle schématu — ne jen syrový Markdown — a zároveň bere z vašich rukou kontejnery, anti-bot vrstvu i copyleft závazky. Prostě jiné nástroje pro různé chutě na infrastrukturu.
Tady je ten rozdíl přehledně:
| Oblast | Firecrawl self-hosted | Thunderbit dev stack (API · MCP · CLI) |
|---|---|---|
| Podoba nasazení | Služba, kterou provozujete (6 kontejnerů) | Hostované API, které voláte |
| Co je potřeba ke startu | docker compose nad 6službovým stackem | API klíč a požadavek |
| Renderování JS | Přibalený playwright-service (běží u vás) | Na serveru, řízeno přepínačem renderMode |
| Strukturovaný výstup | Potřebuje LLM klíč (/extract, json) | POST /extract s JSON Schema |
| Anti-bot vrstva | Self-hosted chybí (Fire-engine je jen v cloudu) | Řešeno na straně serveru |
| Licence | AGPL-3.0 (copyleft pro síťové použití) | Komerční API, bez copyleftu na váš kód |
| Kdy je nejlepší | Chcete plnou kontrolu a provozujete infrastrukturu | Chcete Markdown/strukturovaná data bez ops |
Ani jedno není univerzálně „lepší“. Pokud je pro vás cílem právě provoz platformy — plná kontrola dat, žádná externí závislost a AGPL sedí vašemu scénáři — self-hosted Firecrawl je schopná a aktivně udržovaná volba. Pokud raději zavoláte API a obejdete se bez šestikontejnerového života, přesně to nabízí stack Thunderbit.
Kdo by si měl Firecrawl skutečně self-hostovat
Když odfiltrujeme hype, obraz je dost jasný na to, aby šel rozdělit podle potřeb.
Self-host Firecrawl má smysl, pokud chcete plnou kontrolu nad scrapingovou infrastrukturou, nevadí vám provozovat Redis / RabbitMQ / Postgres / FoundationDB v produkci, vaše požadavky na renderování ospravedlňují container playwright-service a AGPL-3.0 je pro váš způsob nasazení v pořádku. Základní schopnost je reálná: z jedné statické stránky i z JavaScriptem renderované stránky jsem dostal čistý, strukturovaný, LLM-ready Markdown a celý stack běžel na předpřipravených image.
Jděte jinam, pokud chcete jen rychlý lokální skript (tohle je nejtěžší setup v celé sadě, bez debat), potřebujete anti-block na úrovni cloudu, ale nechcete ho provozovat sami (self-hosted Fire-engine nemá), nebo se vám s komerčním plánem bije síťová klauzule AGPL. Pro případ „jen potřebuji z URL dostat Markdown nebo strukturovaná data a nechci řešit provoz“ pokrývá stejnou oblast hostované API jako Thunderbit /distill a /extract bez kontejnerů.
Můj předběžný závěr: silné jádro, těžký provozní závazek a licence, kterou si musíte před komerčním použitím vyjasnit. Pro týmy, které chtějí vlastnit celý pipeline, si místo zaslouží — od ostatních ale chce hodně. Vrátím se k tomu, jakmile otestuji /v1/crawl, vyzkouším /extract s LLM klíčem a ověřím build ze zdrojů na daemonu bez colimy; právě tyhle otevřené otázky stojí mezi tímto pohledem a finálním verdiktem.
Vyzkoušet Thunderbit pro extrakci webových dat Get Started Free
Časté dotazy
Je self-hosted Firecrawl totéž co cloudová verze?
Ne. Self-hosted vám dá základní engine pro převod stránky do Markdownu a renderování JavaScriptu přes přibalený playwright-service, ale neobsahuje Fire-engine, tedy proprietární anti-block vrstvu cloudového produktu. AI funkce jako endpoint /extract a výstup json navíc vyžadují váš vlastní LLM klíč (OpenAI nebo Ollama). V této recenzi jsem testoval jen self-hosted stack; cloudové API bylo mimo záběr.
Kolik kontejnerů Firecrawl self-hosted skutečně potřebuje? Šest: api, playwright-service, redis, rabbitmq, nuq-postgres a foundationdb. Není to jeden binární soubor, ale plnohodnotný service stack — i proto šlo o nejtěžší nastavení ze všech nástrojů v této výzkumné sadě. Počítejte s provozní režií message brokeru, cache a databázové infrastruktury, ne jen se skriptem.
Zvládne Firecrawl při self-hostingu stránky s JavaScriptem?
Ano, v mém testování ano. Přibalený playwright-service vykresluje stránky v reálném prohlížečovém enginu ještě před extrakcí. Ověřil jsem to na quotes.toscrape.com/js/, kde se Einsteinův citát — obsah, který existuje až po spuštění JavaScriptu — objevil v navráceném Markdownu. Právě tahle schopnost vykreslování vysvětluje, proč je jedním ze šesti kontejnerů headless prohlížeč.
Ovlivňuje licence AGPL-3.0 komerční použití? Může, a měli byste to brát jako zásadní otázku. AGPL-3.0 je silný copyleft s klauzulí pro síťové použití, což znamená, že poskytování funkcionality uživatelům přes síť může nést povinnost zpřístupnit zdrojové kódy — i když nikdy nedistribuujete binárku. Pokud plánujete postavit komerční produkt na self-hosted instanci, proberte to s člověkem, který ve vaší firmě řeší licence, ještě než se zavážete. Tohle je upozornění na licenci, ne právní rada.
Jaký je rozdíl mezi Firecrawl a developerskými nástroji Thunderbit?
Firecrawl self-hosted je služba, kterou provozujete vy — šest kontejnerů ve vlastní režii, s podmínkami AGPL-3.0 a bez vestavěné anti-block vrstvy. Developerský stack Thunderbit (Open API, MCP server, CLI) je hostovaný engine, který jen voláte: POST /distill pro Markdown, POST /extract pro strukturovaná data podle JSON Schema, s renderováním JS i anti-bot ochranou na serveru a bez copyleftových povinností na váš vlastní kód. Firecrawl vyhovuje týmům, které chtějí plnou kontrolu nad infrastrukturou; Thunderbit těm, kteří chtějí výstup bez provozní zátěže.
