Firecrawl, strony internetowe jako markdown dla LLM

Firecrawl, strony internetowe jako markdown dla LLM

Firecrawl pobiera stronę internetową, renderuje ją w przeglądarce bezgłowej i zwraca czysty markdown zamiast surowego HTML. Repozytorium firecrawl/firecrawl ma około 170 tysięcy gwiazdek, kod serwera stoi na licencji AGPL-3.0, a oficjalne SDK na MIT. Ta różnica licencyjna jest pierwszą rzeczą do sprawdzenia przed wdrożeniem komercyjnym, bo dotyczy zupełnie innych warstw systemu.

Co Firecrawl właściwie robi

Zadanie brzmi banalnie: wziąć adres i zwrócić tekst. W praktyce między jednym a drugim leży kilka warstw, które trzeba obsłużyć osobno, i to one decydują, czy własne rozwiązanie zajmie tydzień, czy pół roku.

Pierwsza warstwa to pobranie zawartości. Duża część współczesnych stron zwraca pod adresem prawie pusty dokument HTML i dopiero skrypt buduje treść w przeglądarce. Zwykłe żądanie HTTP dostaje wtedy szkielet bez ani jednego zdania. Firecrawl domyślnie uruchamia stronę w przeglądarce sterowanej przez Playwright, czeka na wyrenderowanie i dopiero potem czyta drzewo dokumentu.

Druga warstwa to oczyszczanie. Wyrenderowany dokument zawiera menu nawigacyjne, stopkę, baner zgody na pliki cookie, sekcję z podobnymi artykułami i kilkanaście bloków, które dla modelu językowego są czystym szumem. Opcja onlyMainContent, włączona domyślnie, próbuje zostawić sam korpus treści. Do ręcznego dostrajania służą includeTags i excludeTags, przyjmujące selektory CSS.

Trzecia warstwa to konwersja. Oczyszczone drzewo dokumentu zamienia się w markdown, w którym nagłówki, listy, tabele i bloki kodu zachowują strukturę. Model językowy radzi sobie z tym formatem wyraźnie lepiej niż z HTML, a przy okazji ten sam tekst zajmuje mniej tokenów, bo znikają atrybuty klas i identyfikatory.

Czego Firecrawl nie robi, jest równie istotne. Nie dzieli tekstu na fragmenty, nie liczy wektorów i nie przechowuje niczego długoterminowo. Wynik trzeba samodzielnie pociąć i włożyć do bazy wektorowej, na przykład Chroma albo Pinecone. Nie jest też biblioteką działającą w Twoim procesie. To usługa HTTP, a SDK dla JavaScriptu i Pythona to cienkie klienty, które składają żądanie i rozpakowują odpowiedź.

Ten podział ma konkretne konsekwencje przy planowaniu wdrożenia. Opóźnienie sieciowe wchodzi do każdego wywołania, a limity współbieżności ustala dostawca, a nie Twoja maszyna. Z drugiej strony pobieranie stron nie obciąża procesu aplikacji i nie wymaga trzymania puli przeglądarek w tym samym kontenerze, w którym działa reszta systemu.

Licencja AGPL-3.0 i co z niej wynika

To najważniejsza sekcja tego tekstu, bo tutaj kończy się większość wdrożeń, które nie sprawdziły sprawy zawczasu.

Plik LICENSE w katalogu głównym repozytorium zawiera pełny tekst GNU Affero General Public License w wersji 3, z notą praw autorskich firmy Sideguide Technologies Inc. Nie ma tam żadnej klauzuli dodatkowej, żadnego Commons Clause ani ograniczenia konkurencyjnego. To zwykły, niezmodyfikowany AGPL-3.0, a interfejs GitHuba rozpoznaje go poprawnie i raportuje agpl-3.0.

Plik README opisuje to precyzyjniej: projekt jest licencjonowany głównie na AGPL-3.0, natomiast SDK oraz część komponentów interfejsu na MIT. Ten podział da się sprawdzić w kodzie. Katalogi apps/js-sdk i apps/python-sdk mają własne pliki LICENSE z tekstem MIT. Katalog apps/api, czyli serwer, własnego pliku nie ma, więc podlega licencji z katalogu głównego.

Trzy niezależne źródła dla samych SDK zgadzają się ze sobą, co przy takich projektach nie jest regułą. Paczka firecrawl w wersji 4.34.1 deklaruje w rejestrze npm pole license o wartości MIT, a po pobraniu i rozpakowaniu archiwum plik package/LICENSE faktycznie zawiera tekst MIT z notą Sideguide Technologies Inc. Odpowiednik dla Pythona, firecrawl-py w wersji 4.37.1, również deklaruje MIT w metadanych PyPI. Pakiet firecrawl-mcp idzie na MIT, a narzędzie wiersza poleceń firecrawl-cli na ISC.

Praktyczny wniosek jest taki. Jeśli korzystasz z usługi w chmurze i wołasz ją przez SDK, kod, który piszesz, dotyka wyłącznie warstwy MIT i nie ma tu żadnego problemu. Jeśli natomiast stawiasz serwer u siebie, wchodzisz w zakres AGPL-3.0, a jej sekcja trzynasta mówi o czymś, czego zwykły GPL nie obejmuje: użytkownik korzystający z programu przez sieć ma prawo dostać kod źródłowy wersji, z którą się łączy, jeśli została zmodyfikowana.

Wyjątku dla samodzielnego hostowania nie ma. Ani w pliku licencji, ani w dokumentacji nie pojawia się dodatkowe zezwolenie, które zdejmowałoby ten obowiązek. Nie ma też publicznie ogłoszonej podwójnej licencji, którą można kupić dla własnego wdrożenia. Ścieżką komercyjną bez ryzyka copyleft pozostaje usługa w chmurze albo umowa Enterprise negocjowana indywidualnie.

Osobną, nierozstrzygniętą kwestią jest granica pojęcia utworu pochodnego, kiedy Twoja aplikacja rozmawia z serwerem Firecrawl wyłącznie po HTTP i stoi w osobnym kontenerze. Część zespołów prawnych uznaje takie rozdzielenie za wystarczające, część nie. Nie jest to porada prawna, tylko opis stanu faktycznego: jeśli planujesz samodzielne hostowanie w produkcie komercyjnym, ta decyzja należy do prawnika, a nie do zespołu inżynierskiego.

Endpointy i to, czym się różnią

Interfejs w wersji drugiej wystawia kilka operacji, których nazwy bywają mylone, a każda kosztuje inaczej.

Operacja scrape pobiera jeden adres i zwraca dokument w żądanych formatach. Operacja crawl odkrywa podstrony i pobiera je wszystkie, działając asynchronicznie: dostajesz identyfikator zadania i odpytujesz o status. Operacja map zwraca wyłącznie listę adresów bez treści, co jest najtańszym sposobem, żeby zobaczyć rozmiar witryny przed uruchomieniem właściwego pobierania.

Operacja search łączy wyszukiwanie w sieci z pobieraniem wyników, przyjmując źródła web, news i images oraz kategorie takie jak github czy pdf. Operacja parse przetwarza przesłany plik zamiast adresu. Do tego dochodzą batch scrape dla listy adresów, extract i agent dla wydobywania danych opisanego zdaniem, monitor do cyklicznego sprawdzania stron oraz interact i browser dla sesji przeglądarkowych.

Rozróżnienie między map a crawl warto sobie utrwalić, bo pomyłka bywa kosztowna. Mapowanie liczy się jako jeden kredyt za wywołanie, natomiast pobieranie jako jeden kredyt za każdą stronę. Uruchomienie crawl na dużym serwisie tylko po to, żeby dowiedzieć się, ile ma podstron, potrafi zjeść cały miesięczny limit w kilka minut.

Praktyczna kolejność wygląda więc tak. Najpierw map z polem search, żeby zobaczyć, ile adresów pasuje do interesującego Cię wzorca. Potem scrape na kilku wybranych adresach, żeby sprawdzić jakość oczyszczania i dobrać selektory. Dopiero na końcu crawl z ograniczeniami wynikającymi z dwóch pierwszych kroków. Odwrócenie tej kolejności jest najczęstszym powodem zdziwienia przy pierwszym rachunku.

Instalacja i pierwsze wywołanie

Klient dla JavaScriptu wymaga Node w wersji co najmniej dwudziestej drugiej, co jest zapisane wprost w polu engines paczki. Klient dla Pythona deklaruje zgodność od wersji 3.8 wzwyż i ciągnie za sobą httpx, requests, websockets oraz pydantic w wersji co najmniej drugiej.

# klient dla Pythona
pip install firecrawl-py

# klient dla JavaScriptu, nazwa krótka albo historyczna
npm install firecrawl
npm install @mendable/firecrawl-js

# narzędzie wiersza poleceń, przydatne do szybkiego sprawdzenia
npm install -g firecrawl-cli
firecrawl scrape https://example.com

# klucz odczytywany automatycznie przez oba SDK
export FIRECRAWL_API_KEY=fc-twoj-klucz

Obie paczki w rejestrze npm, firecrawl i @mendable/firecrawl-js, publikowane są z tej samej wersji i mają identyczną zawartość. Nowszy kod używa nazwy krótkiej, starsze poradniki nazwy z przedrostkiem organizacji.

Pierwsze wywołanie w Pythonie wygląda tak. Zwróć uwagę na nazwy pól: SDK dla Pythona używa zapisu z podkreśleniami, a odpowiednik dla JavaScriptu tych samych nazw zapisanych wielbłądzią konwencją.

from firecrawl import Firecrawl

app = Firecrawl(api_key="fc-twoj-klucz")

doc = app.scrape(
    "https://docs.firecrawl.dev",
    formats=["markdown", "links"],
    only_main_content=True,
    exclude_tags=["nav", "footer", ".cookie-banner"],
    wait_for=2000,
    timeout=60000,
    max_age=3600000,
)

print(doc.markdown[:500])
print(len(doc.links))

Pole max_age podaje w milisekundach, jak stara może być zapisana wcześniej wersja strony, żeby dało się ją zwrócić bez ponownego pobierania. Ustawienie zera wymusza świeże pobranie. To jedno pole potrafi obniżyć rachunek i czas odpowiedzi w zadaniach, które wielokrotnie odwiedzają te same adresy.

Formaty wyjściowe i dane strukturalne

Pole formats przyjmuje listę, więc jedno żądanie może zwrócić kilka reprezentacji naraz. Dostępne wartości to między innymi markdown, html, rawHtml, links, images, screenshot, summary, changeTracking, json i attributes.

Najciekawszy jest format json, który zamiast tekstu zwraca dane dopasowane do schematu. Schemat podajesz jako obiekt JSON Schema albo jako model Pydantic, a alternatywnie możesz opisać potrzebę zdaniem w polu prompt. Ta wygoda ma cenę: format json kosztuje cztery kredyty więcej za stronę niż zwykłe pobranie.

from pydantic import BaseModel
from firecrawl import Firecrawl

class Oferta(BaseModel):
    tytul: str
    firma: str
    lokalizacja: str
    zdalna: bool

app = Firecrawl(api_key="fc-twoj-klucz")

wynik = app.scrape(
    "https://example.com/oferty/12345",
    formats=[{"type": "json", "schema": Oferta}],
    only_main_content=False,
)

print(wynik.json["tytul"], wynik.json["firma"])

Do stron, które odsłaniają treść dopiero po interakcji, służy pole actions. Przyjmuje listę kroków wykonywanych w przeglądarce przed odczytaniem dokumentu, a dostępne typy to wait, click, write, press, scroll, screenshot, executeJavascript, pdf oraz scrape. Pozwala to obsłużyć okna modalne, przyciski rozwijające tekst i paginację ukrytą pod przyciskiem.

Warstwa pobierania ma jeszcze kilka pól, które w produkcji okazują się potrzebne. Pole proxy przyjmuje wartości basic, stealth, enhanced i auto i steruje sposobem wychodzenia na zewnątrz. Pole blockAds odcina skrypty reklamowe, removeBase64Images usuwa obrazy wklejone w kod, a location z podpolami country i languages ustawia region, z którego strona ma być widziana.

Crawl i kontrola kosztów

Pobranie całej witryny jest operacją, która najłatwiej wymyka się spod kontroli, dlatego opcje ograniczające zakres warto ustawić od pierwszego uruchomienia, a nie po pierwszym rachunku.

import { Firecrawl } from 'firecrawl'

const app = new Firecrawl({
  apiKey: process.env.FIRECRAWL_API_KEY,
  maxRetries: 3,
  timeoutMs: 120000
})

const job = await app.crawl('https://docs.example.com', {
  limit: 500,
  maxDiscoveryDepth: 3,
  includePaths: ['^/docs/.*'],
  excludePaths: ['^/docs/changelog/.*', '^/docs/.*\\.pdf$'],
  sitemap: 'include',
  crawlEntireDomain: false,
  allowSubdomains: false,
  ignoreQueryParameters: true,
  deduplicateSimilarURLs: true,
  delay: 1,
  maxConcurrency: 5,
  scrapeOptions: {
    formats: ['markdown'],
    onlyMainContent: true,
    blockAds: true
  }
})

console.log(job.status, job.completed, '/', job.total, 'kredyty:', job.creditsUsed)

Pole limit jest jedynym twardym hamulcem i powinno być ustawione zawsze. Pole maxDiscoveryDepth ogranicza głębokość odkrywania nowych adresów, licząc od strony startowej. Pola includePaths i excludePaths przyjmują wyrażenia regularne dopasowywane domyślnie do ścieżki, a nie do całego adresu, chyba że ustawisz regexOnFullURL.

Pole sitemap przyjmuje wartości skip, include i only. Wartość only bywa najlepszym wyborem dla dokumentacji, bo bierze wyłącznie adresy z mapy witryny i pomija odkrywanie przez odnośniki, co eliminuje przypadkowe wejścia w archiwa i filtry.

Pola delay i maxConcurrency decydują o obciążeniu serwera po drugiej stronie. Odpytywanie cudzej witryny z pięćdziesięcioma równoległymi połączeniami to zachowanie, po którym trafia się na listę blokowanych adresów, a czasem do skrzynki działu prawnego. Domyślnie Firecrawl respektuje dyrektywy z pliku robots.txt, a opcja ignoreRobotsTxt pozwala to wyłączyć. Sama możliwość nie oznacza, że wypada z niej korzystać, i sama dokumentacja projektu przypomina, że odpowiedzialność za zgodność z regulaminami odwiedzanych stron leży po stronie użytkownika.

Dla długich zadań dostępny jest obiekt watcher, który emituje zdarzenia z kolejnymi dokumentami zamiast zmuszać do pętli odpytującej o status. Alternatywą jest pole webhook, wysyłające powiadomienia pod wskazany adres.

Firecrawl w potoku RAG

Rzadko kiedy Firecrawl jest ostatnim elementem układanki. W typowym potoku pobiera treść, ktoś inny dzieli ją na fragmenty, a jeszcze ktoś inny liczy wektory i je przechowuje.

Integracja z LangChain mieszka w osobnym pakiecie langchain-firecrawl, wydanym na MIT. Daje FirecrawlLoader z polem mode przyjmującym wartości scrape, crawl, map, extract i search, a oprócz tego komplet narzędzi dla agenta: FirecrawlScrape, FirecrawlCrawl, FirecrawlMap, FirecrawlExtract i FirecrawlSearch.

from langchain_firecrawl import FirecrawlLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter

loader = FirecrawlLoader(
    url="https://docs.example.com",
    mode="crawl",
    params={"limit": 200, "scrapeOptions": {"formats": ["markdown"]}},
)

dokumenty = loader.load()

splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=150)
fragmenty = splitter.split_documents(dokumenty)

print(len(dokumenty), "stron ->", len(fragmenty), "fragmentow")

Po stronie LlamaIndex odpowiednikiem jest FireCrawlWebReader z pakietu llama-index-readers-web, przyjmujący api_key, opcjonalny api_url dla wdrożenia własnego oraz te same tryby pracy. Pakiet wymaga firecrawl-py w wersji co najmniej 4.3.3.

Jeśli budujesz potok, w którym część źródeł to strony, a część to dokumenty biurowe i pliki PDF leżące na dysku, sensowniejszy bywa podział zadań. Firecrawl bierze na siebie sieć, a Unstructured rozkłada pliki lokalne. Gotowe rozwiązanie z interfejsem i bazą w komplecie oferuje RAGFlow, które można zasilać wynikami z Firecrawl zamiast budować własną warstwę pobierania.

Samodzielne hostowanie: co dostajesz, a czego nie

Projekt daje plik docker-compose.yaml i dokumentację przypiętą do konkretnego wydania. Uruchomienie do pierwszego udanego pobrania zajmuje kilkanaście minut, pod warunkiem że nie próbujesz od razu włączyć wszystkiego.

git clone https://github.com/firecrawl/firecrawl.git
cd firecrawl
git checkout v2.11.162

cat > .env <<'EOF'
USE_DB_AUTHENTICATION=false
POSTGRES_USER=postgres
POSTGRES_PASSWORD=zmien-na-co-najmniej-32-losowe-znaki
POSTGRES_DB=postgres
EOF

docker compose up --build -d

# sam sygnal zycia, nie sprawdza kolejki ani przegladarki
curl --fail --silent --max-time 5 http://localhost:3002/v0/health/readiness

# wlasciwy test: jedno prawdziwe pobranie
curl --fail-with-body --silent --max-time 75 \
  -X POST http://localhost:3002/v2/scrape \
  -H 'Content-Type: application/json' \
  -d '{"url":"https://example.com","formats":["markdown"],"timeout":60000}'

Stos uruchamia serwer API wraz z procesami roboczymi, Playwright, Redis, RabbitMQ oraz PostgreSQL pełniący rolę kolejki. Na zewnątrz publikowany jest domyślnie tylko port 3002. Zmienna NUQ_BACKEND przełącza kolejkę na FoundationDB, a BULL_AUTH_KEY odblokowuje panel administracyjny kolejki, ale w pierwszym uruchomieniu obie należy zostawić w spokoju.

Teraz część, którą trzeba znać przed obietnicą złożoną zespołowi. Dokumentacja wymienia wprost, czego domyślny stos nie obsługuje. Zrzuty ekranu i pole actions nie działają, bo obie dostępne ścieżki pobierania zgłaszają brak wsparcia i wymagają osobnej usługi Fire-engine, której w repozytorium nie ma. Funkcje agent, browser, interact oraz wyspecjalizowane formaty w rodzaju product, menu, audio i video są dostępne wyłącznie w chmurze. Formaty korzystające z modelu językowego, w tym json, wymagają podłączenia własnego dostawcy zgodnego z interfejsem OpenAI albo lokalnego Ollamy.

Do tego dochodzą sprawy operacyjne. Domyślna konfiguracja startuje z wyłączonym uwierzytelnianiem API, a plik Compose nie definiuje trwałych wolumenów dla PostgreSQL, Redis ani RabbitMQ. To znaczy, że po podmianie kontenera dane znikają. Wystawienie takiego wdrożenia poza zaufaną sieć bez własnej warstwy uwierzytelniania i terminacji TLS jest zaproszeniem do kłopotów.

Samodzielne hostowanie ma sens, gdy potrzebujesz kontroli nad kodem albo nad tym, gdzie trafiają dane. Nie ma sensu jako sposób na uniknięcie rachunku, bo koszt maszyn i czasu zespołu przy tym stosie łatwo przewyższa abonament, a zakres funkcji jest mniejszy. Warto też policzyć, ile pracy zostaje po stronie zespołu: aktualizacje wydań, rotacja sekretów, monitorowanie kolejki i odtwarzanie po awarii to obowiązki, których nikt za Ciebie nie przejmie.

Cennik chmury i model kredytów

Rozliczenie idzie w kredytach, a nie w żądaniach, więc dwa wywołania o tej samej liczbie mogą kosztować bardzo różnie.

Plan darmowy daje tysiąc kredytów miesięcznie, dwa równoległe zadania i nie wymaga karty. Plan Hobby to 19 dolarów miesięcznie albo 16 dolarów przy płatności rocznej, pięć tysięcy kredytów i pięć równoległych zadań. Plan Standard to 99 dolarów miesięcznie albo 83 dolary rocznie za sto tysięcy kredytów. Plan Growth kosztuje 399 dolarów miesięcznie albo 333 dolary rocznie za pięćset tysięcy kredytów. Plan Scale to 749 dolarów miesięcznie albo 599 dolarów rocznie za milion kredytów, z dopłatą 397 dolarów za każde dodatkowe 350 tysięcy. Plan Enterprise wyceniany jest indywidualnie.

Przelicznik kredytów jest prosty. Pobranie strony, pobranie strony w ramach crawla oraz jedno sprawdzenie w monitorze kosztują po jednym kredycie za stronę. Mapowanie to jeden kredyt za wywołanie. Wyszukiwanie to dwa kredyty za dziesięć wyników. Format json dokłada cztery kredyty do każdej strony. Sesja przeglądarkowa kosztuje dwa kredyty za minutę. Zapytania do indeksu publikacji naukowych są darmowe, a tryb agenta jest w zapowiedzi z pięcioma darmowymi uruchomieniami dziennie i wyceną zależną od zużytych tokenów.

Trzy rzeczy warto sprawdzić przed decyzją. Kredyty nie przechodzą na kolejny miesiąc w planach samoobsługowych, przenoszenie jest dostępne dopiero w Scale i Enterprise. Nie ma rozliczenia za faktyczne zużycie bez abonamentu. Nieudane żądania nie są naliczane.

Jest też rozbieżność w danych o współbieżności, którą lepiej wyjaśnić przed podpisaniem umowy. Strona cennika podaje dla planu Standard dwadzieścia pięć równoległych żądań, a dla Growth pięćdziesiąt. Dokumentacja limitów w tej samej chwili wymienia dla tych planów odpowiednio pięćdziesiąt i sto równoległych przeglądarek. Dla planów Free i Hobby obie liczby się zgadzają i wynoszą dwa oraz pięć. Jeśli współbieżność jest dla Ciebie parametrem krytycznym, poproś o potwierdzenie na piśmie.

Osobno działają limity liczby żądań na minutę. W planie darmowym to dziesięć wywołań scrape, dziesięć map, dziesięć search i tylko dwa crawl.

Firecrawl a alternatywy

Wybór rozstrzyga się zwykle na dwóch pytaniach. Pierwsze dotyczy licencji: jeśli AGPL jest w Twojej organizacji zakazany dla oprogramowania uruchamianego na własnej infrastrukturze, Crawl4AI na Apache-2.0 rozwiązuje problem, choć musisz sam operować przeglądarkami i obejściem zabezpieczeń. Drugie dotyczy skali: przy kilkunastu adresach dziennie własny skrypt na Playwright wystarczy i nie wymaga niczyjego abonamentu. Przy tysiącach adresów dziennie z różnych domen sam koszt utrzymania puli przeglądarek i rotacji adresów wyjściowych przewyższa cenę usługi.

Typowe błędy

Pierwszy to założenie, że skoro SDK jest na MIT, cały projekt jest permisywny. Serwer stoi na AGPL-3.0 i to on ma znaczenie w chwili, gdy przenosisz go na własną infrastrukturę. Warstwy trzeba rozdzielić i opisać osobno w audycie zależności.

Drugi to uruchomienie crawl bez pola limit. Bez tego hamulca zadanie idzie tak daleko, jak pozwolą odnośniki, a przy serwisie z filtrami i paginacją liczba adresów potrafi rosnąć wykładniczo. Zacznij od map i zobacz rozmiar witryny za jeden kredyt.

Trzeci to używanie formatu json tam, gdzie wystarczy markdown. Pięciokrotna różnica w koszcie strony jest niewidoczna przy dziesięciu adresach i bardzo widoczna przy dziesięciu tysiącach. Jeśli i tak przepuszczasz tekst przez własny model, wydobycie danych po swojej stronie bywa tańsze.

Czwarty to obiecanie zrzutów ekranu albo kroków w actions przy wdrożeniu na własnym serwerze. Te funkcje wymagają usługi Fire-engine, której nie ma w repozytorium, więc w domyślnym stosie po prostu nie zadziałają.

Piąty to mylenie pól max_age i store_in_cache. Pierwsze mówi, jak stara zapisana wersja jeszcze Ci odpowiada, drugie decyduje, czy wynik w ogóle zostanie zapisany. Zadanie, które ma widzieć zmiany na stronie w ciągu minut, musi mieć max_age ustawione nisko albo na zero, inaczej dostanie odpowiedź sprzed godzin.

Szósty to potraktowanie zwróconego markdownu jako gotowego wsadu dla modelu. Strona dokumentacji potrafi mieć kilkadziesiąt tysięcy znaków, co przy naiwnym doklejeniu do zapytania zjada okno kontekstu i pogarsza wyniki. Podział na fragmenty i wyszukiwanie wektorowe to osobny etap, którego Firecrawl nie wykonuje.

FAQ

Czy licencja AGPL-3.0 blokuje użycie komercyjne?

Nie blokuje, ale nakłada warunki. Korzystanie z usługi w chmurze przez SDK jest poza zakresem tej licencji, bo SDK są na MIT. Samodzielne uruchomienie serwera wchodzi w zakres AGPL, której sekcja trzynasta wymaga udostępnienia kodu użytkownikom łączącym się przez sieć z wersją zmodyfikowaną. Wyjątku dla samodzielnego hostowania w licencji nie ma, więc przy produkcie komercyjnym decyzję powinien podjąć prawnik.

Czy SDK dla Pythona i JavaScriptu też są na AGPL?

Nie. Katalogi apps/js-sdk i apps/python-sdk mają własne pliki LICENSE z tekstem MIT. Metadane paczek w npm i PyPI deklarują MIT, a rozpakowane archiwum paczki firecrawl w wersji 4.34.1 faktycznie zawiera tekst MIT. Wszystkie trzy źródła są tu zgodne.

Czy własne wdrożenie ma wszystkie funkcje chmury?

Nie ma. Dokumentacja wymienia wprost brak zrzutów ekranu i kroków w actions bez usługi Fire-engine oraz brak trybów agent, browser i interact. Formaty korzystające z modelu językowego wymagają podłączenia własnego dostawcy zgodnego z interfejsem OpenAI albo Ollamy.

Ile kosztuje pobranie tysiąca stron?

Tysiąc kredytów przy zwykłym pobieraniu do markdownu, czyli dokładnie tyle, ile daje plan darmowy w miesiącu. Ten sam tysiąc stron z formatem json to już pięć tysięcy kredytów, bo każda strona kosztuje jeden kredyt plus cztery za wydobycie danych.

Czy Firecrawl respektuje plik robots.txt?

Domyślnie tak, a opcja ignoreRobotsTxt w ustawieniach crawla pozwala to wyłączyć. Dokumentacja projektu zaznacza, że odpowiedzialność za przestrzeganie regulaminów odwiedzanych serwisów spoczywa na użytkowniku, więc wyłączanie tej ochrony jest decyzją prawną, a nie techniczną.

Czy potrzebuję Firecrawl, skoro mam już Playwright?

Przy kilku znanych stronach o stabilnej strukturze własny skrypt jest tańszy i daje pełną kontrolę. Firecrawl zaczyna się opłacać przy wielu różnych domenach, gdzie utrzymanie puli przeglądarek, rotacji adresów wyjściowych i reguł oczyszczania treści staje się osobnym projektem.

Kod źródłowy i plik licencji znajdziesz w repozytorium na GitHubie, dokumentację na docs.firecrawl.dev, a aktualny cennik na stronie z planami.