Większość osób wrzuca Firecrawl do jednego worka z bibliotekami do scrapowania — z kategorii „pip install, napiszę skrypt i gotowe”. To błędne podejście, a różnica ma znaczenie, zanim wpiszesz pierwszą komendę. Firecrawl self-hosted nie jest biblioteką, którą importujesz; to usługa, którą utrzymujesz. A jej uruchomienie oznacza start sześciu kontenerów Docker, które komunikują się ze sobą.
Uruchomiłem self-hosted stack na Macu (arm64, Docker przez colima) bez klucza do chmury, skierowałem endpoint /v1/scrape na kilka demo stron przyjaznych scrapowaniu i sprawdziłem, co wróci. Krótko mówiąc: podstawowa obietnica się obroniła — strona weszła, a na wyjściu dostałem czysty Markdown gotowy dla LLM — ale pod względem konfiguracji było to najbardziej wymagające narzędzie, jakie testowałem w tym zestawie badawczym. To wstępna ocena, nie końcowy werdykt, i jasno zaznaczę, co sprawdziłem, a czego nie.
Firecrawl to usługa, nie biblioteka
Najpierw trzeba poprawić model myślenia. Narzędzia do scrapowania, po które sięga większość deweloperów, to biblioteki: dodajesz zależność, wywołujesz funkcję, a w swoim procesie dostajesz HTML albo sparsowane dane. Firecrawl self-hosted działa inaczej. To uruchomiona platforma z własnym API, z którą rozmawiasz po HTTP.
Oficjalny opis brzmi: „API do wyszukiwania, scrapowania i interakcji z webem na dużą skalę” — i dokładnie taki jest ten produkt: strony wchodzą, czysty Markdown lub dane strukturalne wychodzą. Gdy hostujesz go samodzielnie, nie linkujesz Firecrawl do swojego kodu. Startujesz stack docker compose i strzelasz do endpointu, dokładnie tak jak do dowolnej wewnętrznej mikro-usługi.
Stack, który uruchomiłem, składał się z sześciu usług:
- api — warstwa HTTP, z której faktycznie korzystasz
- playwright-service — headless browser do renderowania JavaScriptu
- redis — kolejka i cache
- rabbitmq — broker wiadomości
- nuq-postgres — wariant Postgresa do stanu zadań
- foundationdb — rozproszony magazyn klucz-wartość
To prawdziwy backend, nie pomocniczy skrypt. Redis, RabbitMQ, Postgres i FoundationDB to infrastruktura klasy enterprise. Zysk jest taki, że Firecrawl ogarnia trudniejsze elementy scrapowania — kolejki, renderowanie, ponawianie prób — za jednym wywołaniem API. Koszt? Teraz Ty utrzymujesz te sześć kontenerów. Warto pamiętać o tym kompromisie, bo przewija się przez całą recenzję.
Dla porządku: testowałem z firecrawl-py 4.32.0 oraz firecrawl-js 4.30.0, pobierając oficjalny gotowy obraz ghcr.io/firecrawl/firecrawl:latest w dniu 2026-07-09. Repozytorium miało wtedy około 148 tys. gwiazdek (to metadane, nie ocena jakości) i jest na licencji AGPL-3.0 — do tego jeszcze wrócę, bo ma to znaczenie przy zastosowaniach komercyjnych.
Test bazowy: strona zamienia się w czysty Markdown
Cały sens istnienia Firecrawl polega na tym, żeby zamienić stronę internetową w Markdown, który LLM naprawdę potrafi przeczytać. To właśnie sprawdziłem jako pierwsze.
Wskazałem /v1/scrape na books.toscrape.com, statyczny katalog stworzony specjalnie do nauki scrapowania. Wynik: 9 222 znaki czystego Markdowna gotowego dla LLM, z poprawnie odczytanym tytułem strony All products | Books to Scrape. To nie był surowy HTML wrzucony do stringa — tylko uporządkowany Markdown z nagłówkami, linkami i odwołaniami do obrazów. Taki wynik można bezpośrednio wrzucić do pipeline’u retrieval albo podać modelowi bez dodatkowego czyszczenia.
To główna moc Firecrawl i self-hosted poradził sobie z tym bez problemów. Jeśli Twoje zadanie brzmi: „daj mi czytelną treść tej strony w Markdownie”, to statyczna strona wróciła dokładnie tak, jak obiecano. To naprawdę przydatna baza — i właśnie dlatego to narzędzie ma tylu zwolenników.
Warto doprecyzować zakres: testowałem tylko ścieżkę /v1/scrape dla pojedynczej strony. Nie sprawdzałem /v1/crawl, czyli wielostronicowego crawlera przechodzącego przez całą witrynę. To osobna funkcja z własnymi trybami awarii, więc nie będę twierdzić, że działa, skoro tego nie uruchomiłem.
Strony JavaScriptowe: dołączony browser zasługuje na swój kontener
Statyczna strona to łatwy przypadek. Trudniejsze pytanie przy każdym scraperze brzmi: co się dzieje, gdy treść pojawia się dopiero po uruchomieniu JavaScriptu — a we współczesnym internecie to większość przypadków.
Właśnie tutaj kontener playwright-service przestaje być narzutem, a staje się sednem sprawy. Wskazałem scraper na quotes.toscrape.com/js/, czyli wersję demo strony, która renderuje cytaty po stronie klienta. Gdyby Firecrawl pobierał tylko surowy HTML, cytatów by tam nie było — bo nie istnieją, dopóki przeglądarka nie uruchomi skryptu strony.
Scrape zwrócił 1 574 znaki Markdowna, a cytat Einsteina był w środku. Ten cytat pojawia się dopiero po wykonaniu JavaScriptu, więc jego obecność dowodzi, że playwright-service faktycznie wyrenderował stronę w prawdziwym silniku przeglądarki, zamiast pobrać pustą powłokę sprzed renderowania.
Czyli jeden z sześciu kontenerów to headless browser — i robi dokładnie to, za co byś go zatrudnił. To konkretne uzasadnienie dla cięższej architektury: nie płacisz tylko za kontenery, ale za możliwość renderowania stron mocno opartych na JS bez budowania własnej automatyzacji przeglądarki. W wielu realnych przypadkach to różnica między użytecznym wynikiem a pustymi divami.
Gdy cel jest zły: strukturalny błąd zamiast awarii
Scrapery spędzają zaskakująco dużo czasu, próbując dotrzeć do rzeczy, które nie działają — martwych hostów, źle wpisanych URL-i, serwerów, które się zawieszają. To, jak narzędzie się wywala, mówi tyle samo co to, jak działa.
Celowo podałem API nieprawidłowy host. Zwrócił uporządkowany HTTP 500 i dalej działał — bez stack trace’a wyrzuconego do klienta, bez padniętego kontenera, bez zawieszonego procesu. Błąd wrócił jako czysta odpowiedź, na której wywołujący może się oprzeć.
To nudne, ale właśnie takie zachowanie jest pożądane w narzędziu, które ma wejść do pipeline’u. Scraper, który panikuje przy złym adresie, nie nadaje się do automatyzacji. Ten odesłał błąd, który można przechwycić i iść dalej. Sprawdziłem tylko jeden scenariusz błędu, więc czytaj to jako „poradził sobie poprawnie z jedną awarią, którą mu zadałem”, a nie jako pełny audyt odporności — ale ten jeden punkt dał właściwy rezultat.
Rzeczywistość konfiguracji: najcięższy start w całym zestawie
A teraz część, której nikt nie pokazuje na zrzucie do posta z launchu. Firecrawl self-hosted był bez przesady najbardziej złożoną konfiguracją spośród wszystkich narzędzi w tym zestawie badawczym — a uruchomiłem ich już sporo.
Sześć kontenerów to bazowy koszt. Ale po drodze trafiłem też na dwa problemy i chcę dokładnie zaznaczyć, czyja była to wina — jak się okazało, nie Firecrawl.
Problem pierwszy: build ze źródeł. Budowanie obrazów ze źródła nie powiodło się wewnątrz mojego środowiska colima przez błąd snapshottera containerd. To znany, sporadyczny konflikt między procesem builda a warstwą storage colima — problem infrastruktury po mojej stronie, nie bug w Firecrawl. Plik compose dokumentuje alternatywę: można użyć oficjalnych gotowych obrazów ghcr.io/firecrawl/* zamiast budować lokalnie. Przesiadłem się na nie i cały stack wystartował bez problemu. Jeśli używasz standardowego demona Dockera, a nie colima, możesz w ogóle tego nie zobaczyć; zaznaczam to jako zastrzeżenie środowiskowe, a sprawdzenie builda contributorskiego na czystym demonie dopisuję do listy braków.
Problem drugi: ochrona SSRF. Moje pierwsze próby scrapowania były blokowane przez ochronę Firecrawl przed prywatnymi IP i SSRF. Dlaczego? Sieć colima mapuje publiczne hosty na adresy 198.18.x.x, które należą do zarezerwowanego zakresu i Firecrawl słusznie traktuje je jako prywatne — więc warstwa bezpieczeństwa zadziałała poprawnie i odmówiła pobrania czegoś, co wyglądało na cel wewnętrzny. Żeby obejść to tylko na potrzeby testów lokalnych, ustawiłem ALLOW_LOCAL_WEBHOOKS=true.
Tego flagi nie wolno bezmyślnie kopiować do produkcji, bo prosi się o incydent. Dlatego warto jasno powiedzieć, czym ona jest: ochrona SSRF to funkcja, nie przeszkoda. To właśnie ona powstrzymuje usługę scrapującą przed skuszeniem się na Twoją sieć wewnętrzną. Wyłączyłem ją, bo osobliwość DNS w colima sprawiała, że moje legalne publiczne cele wyglądały wewnątrz VM jak prywatne. W prawdziwym wdrożeniu nie wyłączaj ochrony SSRF. Jeśli masz zapamiętać jedną operacyjną uwagę z tej recenzji, niech to będzie ta.
Oba problemy, mówiąc wprost, wynikały z uruchamiania Dockera przez colima na laptopie — nie z wad oprogramowania. Z drugiej strony sam ciężar konfiguracji jest realny i został zaprojektowany przez Firecrawl. To nie jest narzędzie do szybkiego lokalnego skryptu; to narzędzie do uruchomienia wtedy, gdy chcesz usługę scrapującą z renderingiem i jesteś gotów utrzymywać dla niej infrastrukturę.
Czego nie testowałem i czego to narzędzie nie daje
Oto, czego nie objąłem testem, i czego narzędzie nie zapewnia.
Self-hosted nie ma Fire-engine. Chmurowy produkt Firecrawl zawiera Fire-engine — zastrzeżoną warstwę antyblokady do omijania zabezpieczeń botów. Zgodnie z własnym SELF_HOST.md projektu, instancje self-hosted tego nie dostają. Jeśli więc wyobrażasz sobie Firecrawl self-hosted, który od razu przełamuje agresywne systemy antybotowe, trzeba ten obraz skorygować — ta funkcja należy do warstwy chmurowej i nie była częścią tego, co uruchamiałem.
API w chmurze nie było testowane. Nie miałem klucza do chmury, więc wszystko powyżej dotyczy wyłącznie self-hosted stacku. Zarządzana usługa cloud — z Fire-engine, hostowanym skalowaniem i funkcjami AI — to inny produkt i nie będę oceniać jego wydajności z zewnątrz. Każde twierdzenie o chmurze traktuj w tej recenzji jako poza zakresem.
Funkcje AI wymagają klucza. Format wynikowy json i endpoint /extract opierają się na LLM, więc trzeba podpiąć klucz OpenAI albo skonfigurować Ollama. Tych ścieżek nie uruchamiałem, więc /extract i strukturalny output json też pozostają w kolumnie „nieprzetestowane”.
Proxy to zastrzeżenie, nie nagłówek. Firecrawl obsługuje konfigurację proxy, ale celowo wspominam o tym na marginesie — to opcja, którą możesz włączyć, a nie powód, dla którego warto wybrać to narzędzie. A self-hosted i tak nadal nie ma chmurowej warstwy antyblokady.
AGPL-3.0 to realna decyzja zgodności. Ten punkt zasługuje na osobny akapit.
Licencja: przeczytaj AGPL-3.0, zanim wdrożysz
Firecrawl jest licencjonowany na AGPL-3.0. To nie jest drobny przypis na dole README — to mocny copyleft z klauzulą użycia sieciowego, który może bezpośrednio wpłynąć na to, czy możesz zbudować komercyjny produkt na bazie self-hosted instancji.
W skrócie: standardowe obowiązki GPL uruchamiają się przy dystrybucji. AGPL idzie dalej — zapis o użyciu sieciowym oznacza, że udostępnianie funkcjonalności użytkownikom przez sieć może być traktowane jako taki rodzaj użycia, który niesie obowiązek udostępnienia kodu źródłowego. Jeśli osadzasz self-hosted Firecrawl w usłudze, do której klienci dochodzą przez internet, ten zapis jest jak najbardziej w grze, a „przecież nie wysłaliśmy binarki” nie jest ucieczką, którą ludzie zwykle zakładają.
Nie jestem prawnikiem, a interpretacja licencji zależy od konkretnego sposobu wdrożenia. Ale przy każdej rekomendacji komercyjnej AGPL-3.0 to kwestia pierwszoplanowa, a nie drobny druk. Skonsultuj to z osobą w firmie odpowiedzialną za licencjonowanie, zanim oprzesz na tym produkt. Wskazanie tego nie jest zarzutem wobec Firecrawl — wiele świetnych narzędzi jest na AGPL — to po prostu fakt, który trzeba mieć na stole od początku.
Gdzie pasuje stack deweloperski Thunderbit
Wypróbuj Thunderbit do ekstrakcji danych z sieci
Jeśli Twój rzeczywisty cel to „strona → Markdown gotowy dla LLM” albo „strona → dane strukturalne”, a sześciokontenerowy koszt operacyjny oraz pytanie o AGPL nie są czymś, czym chcesz się zajmować, to właśnie tę lukę wypełnia stack deweloperski Thunderbit. Ten sam silnik AI, z którego korzysta ponad 100 000 użytkowników rozszerzenia, udostępniony w trzech formach dla zastosowań technicznych — bez przerzucania infrastruktury na Twoją stronę.
- Open API (REST).
POST /distillzamienia stronę w czysty Markdown gotowy dla LLM;POST /extractzwraca dane strukturalne zgodne z definiowanym przez Ciebie JSON Schema. Renderowanie JS, obsługa antybotów i dynamicznej treści dzieją się po stronie serwera — bez browser container, który musisz utrzymywać. FlagarenderMode(none/basic/full) steruje intensywnością renderowania, a endpointy batch obsługują do 100 URL-i dla distill. - Serwer MCP. Oficjalny serwer Model Context Protocol, dzięki któremu agent AI w Claude lub Cursor może scrapować w trakcie zadania:
thunderbit_suggest_fieldsdo zaplanowania ekstrakcji (za darmo),thunderbit_distilldo Markdowna,thunderbit_extractdo danych strukturalnych. Agent decyduje kiedy pobrać dane, nie wychodząc ze swojego środowiska. - CLI.
npx -y @thunderbit/thunderbit-cliuruchamia scrapowanie z terminala, skryptów, CI albo crona — bez przeglądarki i bez stacku, który trzeba pilnować. Możesz od razu pipe’ować wynik do innych narzędzi:thunderbit distill "$URL" -f markdown | claude -p "summarise".
Kontrast z Firecrawl self-hosted jest prosty. Firecrawl self-hosted daje Ci pełną kontrolę i pełną odpowiedzialność operacyjną: sześć kontenerów, ciężar konfiguracji, warunki AGPL i brak Fire-engine do antyblokady. Thunderbit API/MCP/CLI zamienia tę kontrolę na hostowany silnik, który zwraca zgodne ze schematem strukturalne JSON-y — nie tylko surowy Markdown — a przy tym zdejmuje z Ciebie kontenery, warstwę antybotową i obowiązki copyleft. Inne narzędzia dla innych apetytów na infrastrukturę.
Oto ten kompromis w jednym widoku:
| Aspekt | Firecrawl self-hosted | Thunderbit dev stack (API · MCP · CLI) |
|---|---|---|
| Forma wdrożenia | Usługa, którą utrzymujesz (6 kontenerów) | Hostowane API, do którego wysyłasz zapytania |
| Start | docker compose uruchamia 6-usługowy stack | Klucz API, potem request |
| Renderowanie JS | Dołączony playwright-service (uruchamiasz sam) | Po stronie serwera, flaga renderMode |
| Dane strukturalne | Wymaga klucza LLM (/extract, json) | POST /extract z JSON Schema |
| Warstwa antybotowa | Brak w self-hosted (Fire-engine tylko w chmurze) | Obsługiwane po stronie serwera |
| Licencja | AGPL-3.0 (network-use copyleft) | Komercyjne API, bez copyleft na Twoim kodzie |
| Najlepsze, gdy | Chcesz pełnej kontroli i sam utrzymujesz infrastrukturę | Chcesz Markdown/dane strukturalne bez operacyjnego ciężaru |
Żadne z tych rozwiązań nie jest uniwersalnie „lepsze”. Jeśli dla Ciebie uruchamianie platformy jest celem — pełna kontrola nad danymi, brak zewnętrznych zależności i AGPL pasuje do Twojego scenariusza — self-hosted Firecrawl to sprawna, aktywnie rozwijana opcja. Jeśli wolisz po prostu wywołać API i ominąć życie z sześcioma kontenerami, to właśnie jest propozycja stacku Thunderbit.
Kto naprawdę powinien self-hostować Firecrawl
Odrzucając hype, obraz robi się dość klarowny.
Self-host Firecrawl, jeśli chcesz pełnej kontroli nad swoją infrastrukturą scrapującą, masz komfort z utrzymywaniem w produkcji Redis / RabbitMQ / Postgres / FoundationDB, Twoje potrzeby renderowania uzasadniają kontener playwright-service i AGPL-3.0 pasuje do sposobu, w jaki wdrażasz. Podstawowa funkcja jest realna: dostałem czysty, uporządkowany, gotowy dla LLM Markdown zarówno ze strony statycznej, jak i z tej renderowanej przez JS, a cały stack działał na gotowych obrazach.
Szukaj gdzie indziej, jeśli chcesz po prostu szybki lokalny skrypt (to najcięższa konfiguracja w całym zestawie, bez dwóch zdań), potrzebujesz antyblokady klasy chmurowej bez samodzielnego jej utrzymywania (self-hosted nie ma Fire-engine) albo klauzula sieciowego użycia w AGPL gryzie się z Twoim planem komercyjnym. W przypadku „potrzebuję tylko Markdowna albo danych strukturalnych z URL-a, bez operacji” hostowane API, takie jak /distill i /extract Thunderbit, załatwia ten sam problem bez kontenerów.
Mój wstępny wniosek: mocny rdzeń, duży koszt operacyjny i licencja, którą trzeba przejść przed wdrożeniem komercyjnym. To rozwiązanie ma sens dla zespołów, które chcą posiadać cały pipeline — ale wymaga sporo od wszystkich pozostałych. Wrócę do tematu, gdy przetestuję /v1/crawl, uruchomię /extract z kluczem LLM i sprawdzę build ze źródeł na daemonie innym niż colima; to otwarte kwestie między tym tekstem a ostatecznym werdyktem.
Wypróbuj Thunderbit do ekstrakcji danych z sieci Get Started Free
FAQ
Czy self-hosted Firecrawl to to samo co wersja chmurowa?
Nie. Self-hosted daje Ci podstawowy silnik zamieniający stronę na Markdown oraz renderowanie JavaScriptu przez dołączony playwright-service, ale nie zawiera Fire-engine, czyli zastrzeżonej warstwy antyblokady z produktu cloud. Funkcje AI, takie jak endpoint /extract i output json, także wymagają własnego klucza LLM (OpenAI lub Ollama). W tej recenzji testowałem wyłącznie self-hosted stack; API chmurowe było poza zakresem.
Ile kontenerów naprawdę potrzebuje Firecrawl self-hosted? Sześć: api, playwright-service, redis, rabbitmq, nuq-postgres i foundationdb. To pełny stack usługowy, nie pojedynczy binarny plik — właśnie dlatego była to najcięższa konfiguracja spośród wszystkich narzędzi w tym zestawie badawczym. Trzeba uwzględnić narzut związany z utrzymywaniem brokera wiadomości, cache’u i bazy danych, a nie tylko skryptu.
Czy Firecrawl poradzi sobie ze stronami ciężkimi od JavaScriptu, gdy jest self-hosted? Tak, w moich testach. Dołączony playwright-service renderuje stronę w prawdziwym silniku przeglądarki przed ekstrakcją. Potwierdziłem to na quotes.toscrape.com/js/, gdzie cytat Einsteina — treść, która istnieje dopiero po uruchomieniu JavaScriptu — pojawił się w zwróconym Markdownie. Właśnie dlatego jeden z sześciu kontenerów to headless browser.
Czy licencja AGPL-3.0 wpływa na użycie komercyjne? Może wpływać i trzeba traktować to jako kluczowe pytanie. AGPL-3.0 to mocny copyleft z klauzulą użycia sieciowego, co oznacza, że udostępnianie funkcjonalności przez sieć może pociągać za sobą obowiązek udostępnienia kodu źródłowego — nawet jeśli nigdy nie dystrybuujesz binarki. Jeśli planujesz zbudować produkt komercyjny na self-hosted instancji, porozmawiaj z osobą odpowiedzialną za licencje w firmie, zanim się na tym oprzesz. Ta recenzja tylko zwraca uwagę na licencję — nie stanowi porady prawnej.
Jaka jest różnica między Firecrawl a narzędziami deweloperskimi Thunderbit?
Firecrawl self-hosted to usługa, którą sam utrzymujesz — sześć kontenerów uruchamianych u Ciebie, z warunkami AGPL-3.0 i bez wbudowanej warstwy antyblokady. Stack deweloperski Thunderbit (Open API, serwer MCP, CLI) to hostowany silnik, do którego wysyłasz requesty: POST /distill dla Markdowna, POST /extract dla danych strukturalnych zgodnych z JSON Schema, z renderowaniem JS i obsługą antybotów po stronie serwera oraz bez copyleft na własny kod. Firecrawl pasuje zespołom, które chcą pełnej kontroli nad infrastrukturą; Thunderbit tym, którzy chcą wyników bez obciążenia operacyjnego.
