Majoritatea oamenilor pun Firecrawl în aceeași categorie cu bibliotecile de scraping — genul „pip install, scrii un script și gata”. Abordarea asta e greșită, iar diferența contează înainte să tastezi prima comandă. Firecrawl self-hosted nu este o bibliotecă pe care o imporți; este un serviciu pe care îl operezi, iar punerea lui în funcțiune înseamnă să rulezi șase containere Docker care comunică între ele.
Am rulat stack-ul self-hosted pe un Mac (arm64, Docker prin colima), fără cheie cloud, am trimis endpoint-ul său /v1/scrape către câteva site-uri demo prietenoase cu scrapingul și am urmărit ce s-a întors. Pe scurt: promisiunea de bază s-a confirmat — pagina a intrat, iar la ieșire a venit Markdown curat, gata pentru LLM — însă configurarea a fost cea mai grea dintre toate instrumentele pe care le-am trecut prin această bază de cercetare. Este o evaluare provizorie, nu un verdict final, și voi spune clar ce am testat și ce nu.
Firecrawl este un serviciu, nu o bibliotecă
Prima schimbare de mentalitate e asta. Cele mai multe unelte de scraping pe care le folosesc dezvoltatorii sunt biblioteci: adaugi o dependență, apelezi o funcție, primești HTML sau date parsate în propriul tău proces. Firecrawl self-hosted e altceva. Este o platformă care rulează, cu propriul API, și îi vorbești prin HTTP.
Poziționarea oficială este „API-ul pentru a căuta, extrage și interacționa cu webul la scară”, iar forma produsului chiar asta este — pagini intră, Markdown curat sau date structurate ies. Când îl self-hostezi, nu îl legi ca pe o bibliotecă. Ridici un stack docker compose și apelezi un endpoint, exact cum ai face cu orice microserviciu intern.
Stack-ul pe care l-am rulat avea șase servicii:
- api — suprafața HTTP pe care o apelezi efectiv
- playwright-service — un browser headless pentru randarea JavaScript
- redis — coadă și cache
- rabbitmq — broker de mesaje
- nuq-postgres — o variantă de Postgres pentru starea joburilor
- foundationdb — stocare distribuită key-value
Asta e un backend adevărat, nu un script auxiliar. Redis, RabbitMQ, Postgres și FoundationDB sunt infrastructură de nivel industrial. Avantajul e că Firecrawl gestionează părțile complicate ale scrapingului — cozi, randare, retry-uri — printr-un singur apel API. Costul e că acum tu operezi cele șase containere. Ține minte acest compromis; este firul roșu al întregii recenzii.
Pentru referință, am testat cu SDK-urile firecrawl-py 4.32.0 și firecrawl-js 4.30.0, folosind imaginea oficială prebuilt ghcr.io/firecrawl/firecrawl:latest pe 2026-07-09. Repozitoriul avea în acea zi aproximativ 148k de stele (luați asta ca metadată, nu ca scor de calitate), sub licența AGPL-3.0 — un detaliu la care voi reveni, pentru că schimbă calculele dacă vrei utilizare comercială.
Testul de bază: o pagină devine Markdown curat
Motivul pentru care există Firecrawl este să transforme o pagină web în Markdown pe care un LLM chiar îl poate citi. Așa că asta am verificat prima dată.
Am trimis /v1/scrape către books.toscrape.com, un catalog static creat special pentru exerciții de scraping. Rezultatul: 9.222 de caractere de Markdown curat, pregătit pentru LLM, iar titlul paginii All products | Books to Scrape a fost parsat corect. Nu HTML brut aruncat într-un string — ci Markdown structurat, cu heading-uri, linkuri și referințe la imagini păstrate intacte. Genul de ieșire pe care o poți băga direct într-un pipeline de retrieval sau o poți trimite unui model fără o a doua rundă de curățare.
Acesta este punctul forte principal al Firecrawl, iar varianta self-hosted l-a livrat fără probleme. Dacă sarcina ta este „dă-mi conținutul lizibil al acestei pagini în Markdown”, o pagină statică s-a întors exact cum promitea. Este o primitivă cu adevărat utilă, și motivul pentru care tool-ul are urmăritorii pe care îi are.
Merită precizat clar și domeniul testului: am folosit doar calea /v1/scrape pentru o singură pagină. Nu am testat /v1/crawl, crawlerul multi-pagină care parcurge un site întreg. Aceasta este o capacitate separată, cu propriile moduri de eșec, și nu voi pretinde că funcționează dacă nu am rulat-o.
Pagini JavaScript: browserul inclus își câștigă containerul
O pagină statică e cazul ușor. Întrebarea mai grea pentru orice scraper este ce se întâmplă când conținutul apare abia după rularea JavaScript-ului — iar pe webul modern, asta înseamnă de cele mai multe ori.
Aici containerul playwright-service încetează să mai pară un overhead și devine chiar motivul existenței sale. Am trimis scraperul către quotes.toscrape.com/js/, o variantă a site-ului demo care afișează citatele pe client-side. Dacă Firecrawl ar fi preluat doar HTML-ul brut, citatele n-ar fi apărut — ele nu există până când browserul nu execută scriptul paginii.
Scrapingul s-a întors cu 1.574 de caractere de Markdown, iar citatul lui Einstein era acolo. Acest citat este conținut apărut după JavaScript: faptul că există dovedește că playwright-service chiar a randat pagina într-un browser real înainte de extragerea textului, în loc să ia shell-ul gol dinainte de randare.
Așadar, unul dintre cele șase containere este un browser headless, și își face treaba pentru care l-ai angaja. Asta justifică concret arhitectura mai grea: nu plătești doar pentru containere, ci pentru capacitatea de a reda pagini încărcate cu JS fără să-ți construiești singur automatizarea browserului. Pentru multe ținte reale, asta face diferența între output util și niște div-uri goale.
Când ținta e proastă: erori structurate, fără crash
Scraper-ele petrec surprinzător de mult timp îndreptate spre lucruri care nu merg — hosturi moarte, URL-uri greșite, servere care se blochează. Felul în care tool-ul eșuează spune la fel de multe ca felul în care reușește.
Am trimis intenționat API-ului un host invalid. A returnat un HTTP 500 structurat și a continuat să ruleze — fără stack trace aruncat către client, fără container căzut, fără proces blocat. Eroarea a venit ca un răspuns curat, pe care apelantul îl poate trata condițional.
Este comportamentul plictisitor, corect, pe care îl vrei de la ceva ce intră într-un pipeline. Un scraper care intră în panică la o țintă proastă este un scraper pe care nu-l poți automatiza în jurul lui. Acesta a întors o eroare pe care o poți prinde și peste care poți merge mai departe. Am testat doar un singur caz de eroare, deci luați asta drept „a gestionat corect singurul failure pe care i l-am dat”, nu drept un audit complet de reziliență — dar acel punct de date a avut rezultatul corect.
Realitatea setup-ului: cea mai grea ridicare din bază
Acum vine partea pe care nimeni nu o pune în screenshot-ul pentru lansare. Firecrawl self-hosted a fost, fără exagerare, cea mai complicată configurare dintre toate instrumentele din această bază de cercetare — și am pus în funcțiune destule.
Șase containere este costul de bază. Dar am întâmpinat și două probleme pe parcurs, iar aici vreau să fiu exact în privința vinovăției — și, cum s-a dovedit, nu a fost Firecrawl.
Problema 1: build-ul din sursă. Construirea imaginilor din sursă a eșuat în VM-ul meu colima din cauza unei erori de snapshotter containerd. Este o interacțiune cunoscută ca instabilă între procesul de build și stratul de stocare al colima — un hop infrastructural din mediul meu, nu un bug în Firecrawl. Fișierul compose documentează o alternativă: folosește imaginile oficiale prebuilt ghcr.io/firecrawl/* în loc să construiești local. Am făcut trecerea la ele, iar tot stack-ul a pornit curat. Dacă folosești un daemon Docker standard, nu colima, s-ar putea să nu vezi niciodată problema; o marchez ca avertisment de mediu, iar validarea build-ului de contributor pe un daemon curat rămâne pe lista mea de lacune.
Problema 2: protecția SSRF. Primele mele încercări de scraping au fost blocate de protecția Firecrawl împotriva IP-urilor private / SSRF. De ce? Rețeaua colima mapază hostname-urile publice la adrese 198.18.x.x, care se află într-un interval rezervat pe care Firecrawl îl tratează corect ca privat — deci stratul de securitate și-a făcut treaba și a refuzat să preia o țintă care părea internă. Ca să depășesc asta doar pentru testarea locală, am setat ALLOW_LOCAL_WEBHOOKS=true.
Acea variabilă ajunge ușor copiată în producție și provoacă incidente, așa că trebuie să fiu clar: protecția SSRF este o funcție, nu un obstacol. Ea oprește un serviciu de scraping să fie păcălit să lovească rețeaua ta internă. Eu am dezactivat-o pentru că o particularitate a DNS-ului din colima făcea ca țintele mele publice legitime să pară private în VM. Nu dezactiva protecția SSRF într-un deployment real. Dacă reții un singur aspect operațional din această recenzie, reține-l pe acesta.
Pe scurt, ambele probleme au fost artefacte ale rulării Docker prin colima pe un laptop — nu defecte ale software-ului. Pe de altă parte, greutatea setup-ului este reală și ține de Firecrawl prin design. Nu este tool-ul pe care îl alegi când vrei un script local rapid; este tool-ul pe care îl ridici când vrei un serviciu de scraping cu randare și ești dispus să operezi infrastructură pentru el.
Ce nu am testat și ce nu face
Iată ce nu am acoperit și ce nu oferă tool-ul.
Self-hosted nu are Fire-engine. Produsul cloud Firecrawl include Fire-engine, stratul proprietar anti-blocare pentru a trece de apărările bot. Conform propriului SELF_HOST.md, instanțele self-hosted nu îl primesc. Deci, dacă îți imaginezi Firecrawl self-hosted pătrunzând prin sisteme agresive anti-bot din prima, ajustează imaginea — acea capabilitate există în tier-ul cloud și nu a făcut parte din ce am rulat.
API-ul cloud nu a fost testat aici. Nu am avut cheie cloud, deci tot ce este mai sus se referă doar la stack-ul self-hosted. Serviciul cloud gestionat — cu Fire-engine, scaling găzduit și funcții AI — este un produs diferit, iar eu nu îi voi evalua performanța din exterior. Consideră orice afirmație despre cloud ca fiind în afara domeniului acestei recenzii.
Funcțiile AI au nevoie de o cheie. Formatul structurat json și endpoint-ul /extract se bazează pe un LLM, ceea ce înseamnă că trebuie să aduci o cheie OpenAI sau să configurezi Ollama. Nu am exercitat aceste căi, așa că și /extract și output-ul structurat json intră în coloana netestat.
Proxy-urile sunt o notă de subsol, nu titlul principal. Firecrawl suportă configurarea proxy-ului, dar îl notez intenționat ca footnote — este un buton pe care poți să-l rotești, nu motivul pentru care ai alege tool-ul, iar varianta self-hosted rămâne fără stratul anti-bloc al cloud-ului indiferent de asta.
AGPL-3.0 este o decizie reală de conformitate. Merită propriul moment.
Licența: citește AGPL-3.0 înainte să livrezi
Firecrawl este licențiat sub AGPL-3.0. Nu este o frază de umplutură la finalul unui README — este copyleft puternic cu clauză de utilizare prin rețea și poate influența direct dacă poți construi un produs comercial peste o instanță self-hosted.
Pe scurt: obligațiile standard GPL se activează la distribuție. AGPL merge mai departe — prevederea de utilizare prin rețea înseamnă că oferirea funcționalității software-ului către utilizatori printr-o rețea poate conta ca tipul de utilizare care aduce obligații de disponibilitate a codului sursă. Dacă încorporezi Firecrawl self-hosted într-un serviciu la care clienții tăi ajung prin internet, clauza aceea intră clar în joc, iar „dar noi n-am distribuit niciun binar” nu este scăparea pe care mulți o presupun.
Nu sunt avocat, iar interpretarea licenței depinde de modul exact în care îl deployezi. Dar pentru orice recomandare comercială, AGPL-3.0 este o considerație de prim rang, nu un detaliu în notă de subsol. Implică persoana care se ocupă de licențiere în compania ta înainte să construiești pe baza lui. Să semnalez asta nu înseamnă o critică la adresa Firecrawl — există multe unelte excelente sub AGPL — ci doar un fapt pe care trebuie să-l ai pe masă din timp.
Unde se potrivește stack-ul pentru dezvoltatori al Thunderbit
Încearcă Thunderbit pentru extragerea datelor web
Dacă obiectivul tău real este „pagină → Markdown pregătit pentru LLM” sau „pagină → date structurate”, iar taxele operaționale ale celor șase containere plus întrebarea AGPL nu sunt ceva ce vrei să-ți asumi, exact acest gol îl acoperă Thunderbit cu stack-ul său pentru dezvoltatori. Același motor AI din spatele celor peste 100.000 de utilizatori ai extensiei noastre, expus în trei moduri pentru lucru tehnic — iar infrastructura rămâne de partea noastră a liniei.
- Open API (REST).
POST /distilltransformă o pagină în Markdown curat, gata pentru LLM;POST /extractreturnează date structurate după un JSON Schema definit de tine. Randarea JS, tratamentul anti-bot și conținutul dinamic sunt gestionate server-side — fără container de browser pe care să-l rulezi tu. Un parametrurenderMode(none/basic/full) controlează cât de agresiv se face randarea, iar endpoint-urile batch pot procesa până la 100 de URL-uri pentru distill. - Server MCP. Un server oficial Model Context Protocol, astfel încât un agent AI din Claude sau Cursor poate face scraping în timpul sarcinii:
thunderbit_suggest_fieldspentru a planifica o extragere (gratuit),thunderbit_distillpentru Markdown,thunderbit_extractpentru date structurate. Agentul decide când să tragă datele, fără să iasă din mediul său. - CLI.
npx -y @thunderbit/thunderbit-clirulează scraping din terminal, scripturi, CI sau cron — fără browser, fără stack de supravegheat. Poți face pipe direct în alte tool-uri:thunderbit distill "$URL" -f markdown | claude -p "summarise".
Diferența față de Firecrawl self-hosted e clară. Firecrawl self-hosted îți oferă control total și responsabilitate operațională totală: șase containere, greutatea setup-ului, termenii AGPL și lipsa Fire-engine pentru anti-block. Thunderbit, prin API/MCP/CLI, schimbă acest control pe un motor găzduit care returnează JSON structurat corespunzător schemei — nu doar Markdown brut — iar containerele, stratul anti-bot și obligațiile copyleft dispar din grija ta. Tool-uri diferite pentru apetituri diferite pentru infrastructură.
Iată compromisul într-o singură privire:
| Considerație | Firecrawl self-hosted | Thunderbit dev stack (API · MCP · CLI) |
|---|---|---|
| Formă de deployment | Serviciu pe care îl operezi (6 containere) | API găzduit pe care îl apelezi |
| Ca să pornească | docker compose ridică un stack de 6 servicii | Cheie API, apoi request |
| Randare JS | playwright-service inclus (îl rulezi tu) | Server-side, flag renderMode |
| Output structurat | Are nevoie de cheie LLM (/extract, json) | POST /extract cu JSON Schema |
| Strat anti-bot | Nu există în self-hosted (Fire-engine este doar în cloud) | Gestionat server-side |
| Licență | AGPL-3.0 (copyleft la utilizare prin rețea) | API comercial, fără copyleft pe codul tău |
| Cel mai potrivit când | Vrei control total și vei rula infrastructura | Vrei Markdown/date structurate fără ops |
Niciunul dintre ele nu este universal „mai bun”. Dacă pentru tine chiar asta e ideea — control total asupra datelor, fără dependență externă, iar AGPL se potrivește situației tale — Firecrawl self-hosted este o alegere capabilă, întreținută activ. Dacă preferi să faci un apel API și să sari peste viața cu șase containere, atunci acesta este argumentul pentru stack-ul Thunderbit.
Cine ar trebui, de fapt, să self-hosteze Firecrawl
Dacă scoatem hype-ul, imaginea devine suficient de clară încât să poată fi împărțită după nevoi.
Self-host Firecrawl dacă vrei control complet asupra infrastructurii de scraping, ești confortabil să operezi Redis / RabbitMQ / Postgres / FoundationDB în producție, nevoile tale de randare justifică containerul playwright-service și AGPL-3.0 funcționează pentru modul în care deployezi. Capacitatea de bază există cu adevărat: am obținut Markdown curat, structurat și gata pentru LLM atât dintr-o pagină statică, cât și dintr-una randată cu JS, iar întregul stack a rulat pe imagini prebuilt.
Caută altceva dacă vrei un script local rapid (aceasta este cea mai grea configurare din bază, fără discuție), ai nevoie de anti-block de nivel cloud fără să-l operezi tu însuți (self-hosted nu are Fire-engine), sau clauza de utilizare prin rețea din AGPL intră în conflict cu planurile tale comerciale. Pentru cazul „am doar nevoie de Markdown sau date structurate dintr-un URL, fără partea de ops”, un API găzduit precum /distill și /extract de la Thunderbit acoperă aceeași zonă fără containere.
Evaluarea mea provizorie: nucleu puternic, angajament operațional mare și o licență pe care trebuie să o clarifici înainte să construiești comercial. Își merită locul pentru echipele care vor să dețină întregul pipeline — și cere multe de la ceilalți. Voi reveni asupra lui după ce voi rula /v1/crawl, voi folosi /extract cu o cheie LLM și voi valida build-ul din sursă pe un daemon care nu este colima; acestea sunt întrebările deschise dintre această evaluare și un verdict final.
Încearcă Thunderbit pentru extragerea datelor web Get Started Free
Întrebări frecvente
Firecrawl self-hosted este la fel ca versiunea cloud?
Nu. Varianta self-hosted îți oferă engine-ul de bază pentru scraping în Markdown și randare JavaScript prin playwright-service-ul inclus, dar nu include Fire-engine, stratul proprietar anti-blocare al produsului cloud. Funcțiile AI precum endpoint-ul /extract și output-ul json au nevoie și de propria ta cheie LLM (OpenAI sau Ollama). În această recenzie am testat doar stack-ul self-hosted; API-ul cloud a fost în afara domeniului.
Câte containere are nevoie, de fapt, Firecrawl self-hosted? Șase: api, playwright-service, redis, rabbitmq, nuq-postgres și foundationdb. Este un stack complet de servicii, nu un singur binar — motiv pentru care a fost cea mai grea configurare dintre toate tool-urile din această bază de cercetare. Ia în calcul overhead-ul operațional al rulării infrastructurii de broker de mesaje, cache și baze de date, nu doar al unui script.
Poate Firecrawl să gestioneze pagini încărcate cu JavaScript când este self-hosted? Da, în testele mele. Containerul playwright-service inclus randă paginile într-un browser real înainte de extragere. Am confirmat asta pe quotes.toscrape.com/js/, unde citatul lui Einstein — conținut care există doar după rularea JavaScript-ului — a apărut în Markdown-ul returnat. Tocmai această capabilitate de randare justifică existența browserului headless dintre cele șase containere.
Licența AGPL-3.0 afectează utilizarea comercială? Poate, și ar trebui tratată ca o întrebare de prim ordin. AGPL-3.0 este copyleft puternic cu clauză de utilizare prin rețea, ceea ce înseamnă că oferirea funcționalității software-ului către utilizatori printr-o rețea poate aduce obligații de disponibilitate a codului sursă — chiar dacă nu distribui niciodată un binar. Dacă intenționezi să construiești un produs comercial pe o instanță self-hosted, vorbește cu persoana care se ocupă de licențiere în compania ta înainte să te angajezi. Această recenzie semnalează licența; nu este consultanță juridică.
Care este diferența dintre Firecrawl și tool-urile pentru dezvoltatori ale Thunderbit?
Firecrawl self-hosted este un serviciu pe care îl operezi — șase containere pe care le rulezi tu, cu termeni AGPL-3.0 și fără strat anti-bloc integrat. Stack-ul pentru dezvoltatori Thunderbit (Open API, server MCP, CLI) este un motor găzduit pe care îl apelezi: POST /distill pentru Markdown, POST /extract pentru date structurate conform JSON Schema, cu randare JS și tratament anti-bot pe server și fără obligații copyleft asupra propriului tău cod. Firecrawl se potrivește echipelor care vor control total asupra infrastructurii; Thunderbit se potrivește celor care vor rezultatul fără povara operațională.
