De meeste mensen zien Firecrawl als een van die scraping-bibliotheken – je weet wel, pip install, scriptje schrijven, en klaar is Kees. Maar die aanpak klopt niet, en het is belangrijk om dat verschil te snappen voordat je ook maar één commando intikt. Firecrawl self-hosted is geen bibliotheek die je importeert; het is een dienst die je zelf beheert. Om het op te zetten, moet je zes Docker-containers draaien die met elkaar communiceren.
Ik heb de self-hosted stack op een Mac (arm64, Docker via colima) zonder cloud-sleutel gedraaid, het /v1/scrape eindpunt gericht op een paar scraping-vriendelijke demowebsites, en gekeken wat eruit kwam. Kort gezegd: de kernbelofte werd waargemaakt – een pagina erin, schone LLM-ready Markdown eruit – maar de setup was de zwaarste van alle tools die ik in dit onderzoek heb getest. Dit is een voorlopige blik, geen definitieve beoordeling, en ik zal duidelijk zijn over wat ik wel en niet heb getest.
Firecrawl is een Dienst, Geen Bibliotheek
Dit is het mentale model dat je eerst moet aanpassen. De scraping-tools waar de meeste ontwikkelaars naar grijpen, zijn bibliotheken: je voegt een afhankelijkheid toe, roept een functie aan, en krijgt HTML of geparseerde gegevens terug binnen je eigen proces. Firecrawl self-hosted is een heel ander beestje. Het is een draaiend platform met een eigen API, en je communiceert ermee via HTTP.
De officiële positionering is "de API om het web op schaal te zoeken, scrapen en ermee te interageren," en het product is precies dat – pagina's erin, schone Markdown of gestructureerde gegevens eruit. Wanneer je self-host, link je niet tegen Firecrawl. Je brengt een docker compose stack omhoog en raakt een eindpunt, net zoals je een interne microservice zou aanroepen.
De stack die ik draaide bestond uit zes services:
- api — de HTTP-interface die je daadwerkelijk aanroept
- playwright-service — een headless browser voor JavaScript-rendering
- redis — wachtrij en cache
- rabbitmq — message broker
- nuq-postgres — een Postgres-variant voor job-status
- foundationdb — gedistribueerde key-value opslag
Dat is een echte backend, geen hulpscript. Redis, RabbitMQ, Postgres en FoundationDB zijn op zichzelf al industriële infrastructuur. Het voordeel is dat Firecrawl de rommelige delen van scraping – queuing, rendering, retries – afhandelt achter één API-aanroep. De kosten zijn dat je nu die zes containers beheert. Houd die afweging in gedachten; het is de rode draad van deze hele review.
Ter referentie, ik heb getest tegen de firecrawl-py 4.32.0 en firecrawl-js 4.30.0 SDK's, waarbij ik de officiële voorgebouwde ghcr.io/firecrawl/firecrawl:latest image op 2026-07-09 heb gebruikt. De repository heeft op die datum ongeveer 148k sterren (noem het metadata, geen kwaliteitsscore), onder een AGPL-3.0 licentie – een detail waar ik op terugkom, omdat het de berekening voor commercieel gebruik verandert.
De Kern Test: Een Pagina Wordt Schone Markdown
De hele reden dat Firecrawl bestaat, is om een webpagina om te zetten in Markdown die een LLM daadwerkelijk kan lezen. Dat is dus het eerste wat ik controleerde.
Ik richtte /v1/scrape op books.toscrape.com, een statische catalogus die specifiek is gebouwd voor scraping-oefeningen. Het resultaat: 9.222 tekens schone, LLM-ready Markdown, met de paginatitel All products | Books to Scrape correct geparseerd. Geen ruwe HTML gedumpt in een string – gestructureerde Markdown, met koppen, links en afbeeldingsreferenties intact. Het soort uitvoer dat je direct in een retrieval pipeline zou kunnen plaatsen of aan een model zou kunnen voeren zonder een tweede opschoonronde.
Dit is Firecrawl's belangrijkste kracht, en self-hosted leverde het zonder problemen. Als jouw taak is "geef me de leesbare inhoud van deze pagina als Markdown," kwam een statische pagina precies zoals geadverteerd terug. Dat is een oprecht nuttige primitief, en het is de reden dat de tool de aanhang heeft die het heeft.
Het is belangrijk om precies te zijn over de reikwijdte: ik heb het single-page /v1/scrape pad gebruikt. Ik heb /v1/crawl, de multi-page crawler die een hele site doorloopt, niet getest. Dat is een aparte functionaliteit met zijn eigen faalmodi, en ik ga niet beweren dat het werkt als ik het niet heb uitgevoerd.
JavaScript Pagina's: De Gebundelde Browser Verdient Zijn Container
Een statische pagina is het gemakkelijke geval. De moeilijkere vraag voor elke scraper is wat er gebeurt wanneer de inhoud pas verschijnt nadat JavaScript is uitgevoerd – wat, op het moderne web, meestal het geval is.
Dit is waar die playwright-service container ophoudt overhead te zijn en het punt begint te worden. Ik richtte de scraper op quotes.toscrape.com/js/, een versie van de demosite die zijn quotes client-side rendert. Als Firecrawl alleen de ruwe HTML zou ophalen, zouden de quotes er niet zijn – ze bestaan pas nadat de browser het script van de pagina uitvoert.
De scrape kwam terug met 1.574 tekens Markdown, en de Einstein-quote zat erin. Die quote is post-JavaScript-inhoud: de aanwezigheid ervan is het bewijs dat de playwright-service de pagina daadwerkelijk in een echte browser-engine heeft gerenderd voordat de tekst werd geëxtraheerd, in plaats van de lege pre-render shell te pakken.
Dus een van de zes containers is een headless browser, en die doet het werk waarvoor je hem zou inhuren. Dat is de concrete rechtvaardiging voor de zwaardere architectuur: je betaalt niet alleen voor containers, je betaalt voor de mogelijkheid om JS-zware pagina's te renderen zonder je eigen browserautomatisering aan te sluiten. Voor veel real-world doelen is dat het verschil tussen bruikbare uitvoer en lege divs.
Wanneer het Doel Slecht Is: Gestructureerde Fouten, Geen Crash
Scrapers besteden een verrassend groot deel van hun leven aan dingen die niet werken – dode hosts, getypte URL's, servers die vastlopen. Hoe een tool faalt, is net zo veelzeggend als hoe het slaagt.
Ik heb de API opzettelijk een ongeldige host gegeven. Het retourneerde een gestructureerde HTTP 500 en bleef draaien – geen stack trace uitgespuugd naar de client, geen container die omviel, geen vastgelopen proces. De fout kwam terug als een schone respons waarop de aanroeper kan vertakken.
Dat is het saaie, correcte gedrag dat je wilt van iets dat je in een pijplijn zou plaatsen. Een scraper die in paniek raakt bij een slecht doel, is een scraper waar je niet omheen kunt automatiseren. Deze gaf een fout terug die je kunt opvangen en waar je mee verder kunt. Ik heb slechts één foutgeval getest, dus lees dit als "handelde de ene fout die ik erin gooide correct af," niet als een uitputtende veerkrachtaudit – maar het ene datapunt was het juiste resultaat.
Setup Realiteit: De Zwaarste Klus in de Basis
Nu het deel dat niemand screenshot voor de lanceringstweet. Firecrawl self-hosted was, zonder overdrijving, de meest betrokken setup van elke tool in dit onderzoek – en ik heb er veel opgestart.
Zes containers is de basiskosten. Maar ik stuitte ook op twee problemen onderweg, en ik wil precies zijn over wiens schuld ze waren – niet die van Firecrawl, zo blijkt.
Probleem één: de build vanuit de bron. Het bouwen van de images vanuit de bron mislukte binnen mijn colima VM vanwege een containerd snapshotter-fout. Dat is een bekende, onstabiele interactie tussen de build en de opslaglaag van colima – een infrastructuurprobleem in mijn omgeving, geen bug in Firecrawl. Het compose-bestand documenteert een alternatief: gebruik de officiële voorgebouwde ghcr.io/firecrawl/* images in plaats van lokaal te bouwen. Ik ben overgestapt op die, en de hele stack kwam schoon omhoog. Als je een standaard Docker-daemon gebruikt in plaats van colima, zie je dit misschien helemaal niet; ik markeer het als een omgevingsvoorbehoud, en het valideren van de contributor build op een schone daemon staat op mijn lijst met openstaande punten.
Probleem twee: de SSRF-beveiliging. Mijn eerste scrapes werden geblokkeerd door Firecrawl's private-IP / SSRF-beveiliging. Waarom? De netwerken van colima mappen openbare hostnamen naar 198.18.x.x adressen, die zich in een gereserveerd bereik bevinden dat Firecrawl terecht als privé beschouwt – dus de beveiligingslaag deed zijn werk en weigerde op te halen wat eruitzag als een intern doel. Om dit alleen voor lokale tests te omzeilen, heb ik ALLOW_LOCAL_WEBHOOKS=true ingesteld.
Die vlag wordt gekopieerd naar productie en veroorzaakt incidenten, dus wees precies over wat het is: de SSRF-beveiliging is een functie, geen obstakel. Het is wat voorkomt dat een scraping-service wordt misleid om je interne netwerk te raken. Ik heb het uitgeschakeld omdat een eigenaardigheid van colima's DNS mijn legitieme openbare doelen er privé deed uitzien binnen de VM. Schakel SSRF-beveiliging niet uit in een echte implementatie. Als je één operationele opmerking uit deze review haalt, neem dan deze.
Beide problemen waren, om het duidelijk te zeggen, artefacten van het draaien van Docker via colima op een laptop – geen defecten in de software. Aan de andere kant is het gewicht van de setup zelf reëel en is het Firecrawl's ontwerp. Dit is niet de tool waar je naar grijpt als je een snel lokaal script wilt; het is de tool die je opzet als je een rendering-capabele scraping-service wilt en bereid bent daarvoor infrastructuur te draaien.
Wat Ik Niet Heb Getest, en Wat Het Niet Doet
Hier is wat ik niet heb behandeld, en wat de tool je niet geeft.
Self-hosted heeft geen Fire-engine. Firecrawl's cloudproduct omvat Fire-engine, de eigen anti-blokkeerlaag voor het omzeilen van bot-verdedigingen. Volgens de eigen SELF_HOST.md van het project krijgen self-hosted instanties dit niet. Dus als je je voorstelt dat self-hosted Firecrawl agressieve anti-bot-systemen out-of-the-box doorbreekt, pas dan het beeld aan – die functionaliteit bevindt zich in de cloud-tier, en maakte geen deel uit van wat ik heb uitgevoerd.
De cloud API is hier niet getest. Ik had geen cloud-sleutel, dus alles hierboven betreft alleen de self-hosted stack. De beheerde cloudservice – met Fire-engine, gehoste schaalbaarheid en de AI-functies – is een ander product, en ik ga de prestaties ervan niet van buitenaf karakteriseren. Beschouw elke cloudclaim als buiten de reikwijdte van deze review.
AI-functies vereisen een sleutel. Het json gestructureerde uitvoerformaat en het /extract eindpunt leunen op een LLM, wat betekent dat je een OpenAI-sleutel moet meenemen of Ollama moet aansluiten. Dat plaatst de modelkeuze in de materiaallijst: vergelijk voordat je je aan een setup verbindt de huidige API-prijzen van de providers die je zou kunnen gebruiken. Ik heb die paden niet gebruikt, dus /extract en gestructureerde json uitvoer staan ook in de niet-geteste kolom.
Proxy's zijn een voorbehoud, geen hoofdzaak. Firecrawl ondersteunt proxy-configuratie, maar ik noem het bewust als een voetnoot – het is een knop die je kunt omzetten, geen reden om de tool te kiezen, en self-hosted mist nog steeds de anti-blokkeerlaag van de cloud, ongeacht.
AGPL-3.0 is een echte compliance-beslissing. Dit verdient een eigen paragraaf.
De Licentie: Lees AGPL-3.0 Voordat Je Levert
Firecrawl is gelicentieerd onder AGPL-3.0. Dat is geen wegwerpzin onderaan een README – het is sterke copyleft met een netwerkgebruiksclausule, en het kan direct van invloed zijn op de vraag of je een commercieel product kunt bouwen bovenop een self-hosted instantie.
Kort gezegd: standaard GPL verplichtingen treden in werking bij distributie. AGPL gaat verder – de netwerkgebruiksbepaling betekent dat het aanbieden van de functionaliteit van de software aan gebruikers via een netwerk kan tellen als het soort gebruik dat verplichtingen met zich meebrengt met betrekking tot de beschikbaarheid van de broncode. Als je self-hosted Firecrawl inbedt in een service die je klanten via internet bereiken, valt die clausule vierkant binnen de reikwijdte, en "we hebben nooit een binary geleverd" is niet de ontsnappingsroute die mensen veronderstellen.
Ik ben geen advocaat, en licentie-interpretatie hangt af van hoe je precies implementeert. Maar voor elke commerciële aanbeveling is AGPL-3.0 een eersteklas overweging, geen kleine lettertjes. Betrek degene die verantwoordelijk is voor licenties binnen je bedrijf voordat je erop bouwt. Dit is geen kritiek op Firecrawl – veel uitstekende tools zijn AGPL – het is gewoon een feit dat je vroeg op tafel moet hebben.
Waar Thunderbit's Ontwikkelaarsstack Past
Probeer Thunderbit voor Web Data Extraction
Als je eigenlijke doel "pagina → LLM-ready Markdown" of "pagina → gestructureerde gegevens" is, en de operationele belasting van zes containers plus de AGPL-vraag zijn geen dingen die je wilt bezitten, dan is dat precies de leemte waarvoor de ontwikkelaarsstack van Thunderbit is gebouwd. Dezelfde AI-engine achter onze 100.000+ extensiegebruikers, op drie manieren blootgesteld voor technisch werk – met de infrastructuur aan onze kant van de lijn.
- Open API (REST).
POST /distillzet een pagina om in schone, LLM-ready Markdown;POST /extractretourneert gestructureerde gegevens tegen een JSON Schema die je definieert. JS-rendering, anti-bot-afhandeling en dynamische inhoud worden server-side afgehandeld – geen browsercontainer die je hoeft te draaien. EenrenderMode-vlag (none/basic/full) regelt hoe hard het rendert, en batch-eindpunten verwerken tot 100 URL's voor distillatie. - MCP-server. Een officiële Model Context Protocol server, zodat een AI-agent binnen Claude of Cursor midden in een taak kan scrapen:
thunderbit_suggest_fieldsom een extractie te plannen (gratis),thunderbit_distillvoor Markdown,thunderbit_extractvoor gestructureerde gegevens. De agent beslist wanneer gegevens moeten worden opgehaald zonder zijn omgeving te verlaten. - CLI.
npx -y @thunderbit/thunderbit-clivoert scrapes uit vanaf de terminal, scripts, CI of cron – geen browser, geen stack om in de gaten te houden. Pijp het direct naar andere tools:thunderbit distill "$URL" -f markdown | claude -p "summarise".
Het contrast met self-hosted Firecrawl is duidelijk. Firecrawl self-hosted geeft je volledige controle en volledig operationeel eigenaarschap: zes containers, het gewicht van de setup, de AGPL-voorwaarden en geen Fire-engine voor anti-blokkering. Thunderbit's API/MCP/CLI ruilt die controle in voor een gehoste engine die schema-gematchte gestructureerde JSON retourneert – niet alleen ruwe Markdown – met de containers, de anti-bot-laag en de copyleft-verplichtingen van je bord. Verschillende tools voor verschillende behoeften aan infrastructuur.
Hier is de afweging in één oogopslag:
| Overweging | Firecrawl self-hosted | Thunderbit dev stack (API · MCP · CLI) |
|---|---|---|
| Implementatievorm | Dienst die je beheert (6 containers) | Gehoste API die je aanroept |
| Om aan de slag te gaan | docker compose up een 6-service stack | API-sleutel, dan aanvraag |
| JS-rendering | Gebundelde playwright-service (jij draait het) | Server-side, renderMode vlag |
| Gestructureerde uitvoer | Vereist LLM-sleutel (/extract, json) | POST /extract met JSON Schema |
| Anti-bot-laag | Geen self-hosted (Fire-engine is alleen cloud) | Server-side afgehandeld |
| Licentie | AGPL-3.0 (netwerkgebruik copyleft) | Commerciële API, geen copyleft op jouw code |
| Het beste wanneer | Je volledige controle wilt en infrastructuur wilt draaien | Je Markdown/gestructureerde gegevens wilt zonder operationele last |
Geen van beide is universeel "beter." Als het draaien van het platform het punt voor jou is – volledige gegevenscontrole, geen externe afhankelijkheid, en AGPL past bij jouw situatie – dan is self-hosted Firecrawl een capabele, actief onderhouden keuze. Als je liever een API-aanroep doet en het zes-containerleven overslaat, dan is dat de pitch voor de Thunderbit-stack.
Wie Zou Firecrawl Daadwerkelijk Zelf Moeten Hosten
Stroop de hype weg en het beeld is duidelijk genoeg om te sorteren op behoefte.
Host Firecrawl zelf als je volledige controle wilt over je scraping-infrastructuur, je comfortabel bent met het draaien van Redis / RabbitMQ / Postgres / FoundationDB in productie, je rendering-behoeften de playwright-service container rechtvaardigen, en AGPL-3.0 werkt voor hoe je implementeert. De kernfunctionaliteit is reëel: ik kreeg schone, gestructureerde, LLM-ready Markdown uit zowel een statische als een JS-gerenderde pagina, en de hele stack draaide op voorgebouwde images.
Kijk elders als je een snel lokaal script wilt (dit is de zwaarste setup in de basis, punt uit), je cloud-grade anti-blokkering nodig hebt zonder het zelf te beheren (self-host heeft geen Fire-engine), of de AGPL-netwerkgebruiksclausule botst met je commerciële plannen. Voor het geval "ik heb gewoon Markdown of gestructureerde gegevens van een URL nodig, zonder de operationele last," dekt een gehoste API zoals Thunderbit's /distill en /extract hetzelfde terrein zonder de containers.
Mijn voorlopige conclusie: sterke kern, zware operationele inzet, en een licentie die je moet afhandelen voordat je commercieel bouwt. Het verdient zijn plaats voor teams die de hele pijplijn willen bezitten – en het vraagt veel van alle anderen. Ik zal hierop terugkomen zodra ik /v1/crawl heb uitgevoerd, /extract heb gebruikt met een LLM-sleutel, en de build vanuit de bron heb gevalideerd op een niet-colima daemon; dat zijn de openstaande vragen tussen dit en een definitief oordeel.
Probeer Thunderbit voor Web Data Extraction Get Started Free
Veelgestelde Vragen
Is self-hosted Firecrawl hetzelfde als de cloudversie?
Nee. Self-hosted geeft je de kern scrape-naar-Markdown-engine en JavaScript-rendering via de gebundelde playwright-service, maar het omvat geen Fire-engine, de eigen anti-blokkeerlaag van het cloudproduct. AI-functies zoals het /extract-eindpunt en json-uitvoer vereisen ook je eigen LLM-sleutel (OpenAI of Ollama). In deze review heb ik alleen de self-hosted stack getest; de cloud-API viel buiten de reikwijdte.
Hoeveel containers heeft self-hosted Firecrawl eigenlijk nodig? Zes: api, playwright-service, redis, rabbitmq, nuq-postgres en foundationdb. Het is een volledige servicestack, geen enkele binary – daarom was het de zwaarste setup van elke tool in dit onderzoek. Plan voor de operationele overhead van het draaien van message-broker-, cache- en database-infrastructuur, niet alleen een script.
Kan Firecrawl JavaScript-zware pagina's aan wanneer self-hosted? Ja, in mijn tests. De gebundelde playwright-service rendert pagina's in een echte browser-engine vóór extractie. Ik bevestigde dit op quotes.toscrape.com/js/, waar de Einstein-quote – inhoud die pas bestaat nadat JavaScript is uitgevoerd – verscheen in de geretourneerde Markdown. Die rendering-mogelijkheid is precies waarom een van de zes containers een headless browser is.
Heeft de AGPL-3.0 licentie invloed op commercieel gebruik? Dat kan, en je moet het als een eerstegraads vraag behandelen. AGPL-3.0 is sterke copyleft met een netwerkgebruiksclausule, wat betekent dat het aanbieden van de functionaliteit van de software aan gebruikers via een netwerk verplichtingen met zich mee kan brengen met betrekking tot de beschikbaarheid van de broncode – zelfs als je nooit een binary distribueert. Als je van plan bent een commercieel product te bouwen op een self-hosted instantie, praat dan met degene die verantwoordelijk is voor licenties binnen je bedrijf voordat je je vastlegt. Deze review markeert de licentie; het is geen juridisch advies.
Wat is het verschil tussen Firecrawl en de ontwikkelaarstools van Thunderbit?
Firecrawl self-hosted is een dienst die je beheert – zes containers die je zelf draait, met AGPL-3.0 voorwaarden en geen ingebouwde anti-blokkeerlaag. Thunderbit's ontwikkelaarsstack (Open API, MCP-server, CLI) is een gehoste engine die je aanroept: POST /distill voor Markdown, POST /extract voor JSON-Schema-gestructureerde gegevens, met JS-rendering en anti-bot-afhandeling server-side en geen copyleft-verplichting op je eigen code. Firecrawl is geschikt voor teams die volledige infrastructuurcontrole willen; Thunderbit is geschikt voor degenen die de uitvoer willen zonder de operationele last.
