De fleste placerer Firecrawl i samme kategori som scrape-biblioteker — altså “pip install, skriv et script, færdig”-kategorien. Den forståelse er forkert, og forskellen betyder noget, før du overhovedet skriver én eneste kommando. Firecrawl self-hosted er ikke et bibliotek, du importerer; det er en tjeneste, du driver, og at få den op at køre betyder, at du skal starte seks Docker-containere, som taler sammen.
Jeg kørte self-hosted-stakken på en Mac (arm64, Docker via colima) uden cloud-nøgle, pegede dens /v1/scrape-endpoint mod et par demo-sider, der er venlige over for scraping, og så hvad der kom tilbage. Den korte version: kerne-løftet holdt — en side gik ind, rent LLM-klart Markdown kom ud — men opsætningen var den tungeste af alle de værktøjer, jeg har kørt gennem dette research-setup. Det her er et foreløbigt kig, ikke en endelig bedømmelse, og jeg vil være helt tydelig om, hvad jeg testede, og hvad jeg ikke gjorde.
Firecrawl er en tjeneste, ikke et bibliotek
Det er først og fremmest den mentale model, der skal rettes til. De scrape-værktøjer, de fleste udviklere griber efter, er biblioteker: du tilføjer en afhængighed, kalder en funktion og får HTML eller parserede data tilbage i din egen proces. Firecrawl self-hosted er en anden størrelse. Det er en kørende platform med sit eget API, og du taler til den via HTTP.
Den officielle positionering er “the API to search, scrape, and interact with the web at scale”, og produktformen er præcis dét — sider ind, rent Markdown eller strukturerede data ud. Når du self-hoster, kobler du dig ikke til Firecrawl som et bibliotek. Du starter en docker compose-stack og rammer et endpoint, præcis som du ville gøre med en intern mikrotjeneste.
Stakken, jeg kørte, bestod af seks services:
- api — den HTTP-overflade, du faktisk kalder
- playwright-service — en headless browser til JavaScript-rendering
- redis — kø og cache
- rabbitmq — message broker
- nuq-postgres — en Postgres-variant til jobstatus
- foundationdb — distribueret key-value-lagring
Det er en rigtig backend, ikke et hjælpescript. Redis, RabbitMQ, Postgres og FoundationDB er alle i sig selv tung infrastruktur. Gevinsten er, at Firecrawl håndterer de rodet dele af scraping — køstyring, rendering, retries — bag ét API-kald. Prisen er, at du nu selv skal drifte de seks containere. Hav den afvejning i baghovedet; den går igen gennem hele anmeldelsen.
Til reference testede jeg mod firecrawl-py 4.32.0 og firecrawl-js 4.30.0 SDK’erne og trak det officielle forbyggede ghcr.io/firecrawl/firecrawl:latest-image den 2026-07-09. Repoet lå på omtrent 148k stars på det tidspunkt (betragt det som metadata, ikke en kvalitetsbedømmelse), under en AGPL-3.0-licens — en detalje, jeg kommer tilbage til, fordi den ændrer regnestykket for kommerciel brug.
Kerne-testen: En side bliver til rent Markdown
Hele pointen med Firecrawl er at gøre en webside til Markdown, som en LLM faktisk kan læse. Så det var det første, jeg tjekkede.
Jeg pegede /v1/scrape mod books.toscrape.com, et statisk katalog bygget specifikt til scraping-øvelser. Resultatet: 9.222 tegn rent, LLM-klart Markdown, hvor sidetitlen All products | Books to Scrape blev fortolket korrekt. Ikke rå HTML dumpet i en streng — struktureret Markdown med overskrifter, links og billedreferencer intakte. Den slags output, du direkte kunne smide ind i en retrieval-pipeline eller fodre til en model uden et ekstra oprydningspas.
Det her er Firecrawls største styrke, og self-hosted leverede det uden drama. Hvis din opgave er “giv mig det læsbare indhold fra den her side som Markdown”, så kom en statisk side tilbage præcis som lovet. Det er en virkelig nyttig grundfunktion, og det er grunden til, at værktøjet har den opmærksomhed, det har.
Det er værd at være præcis om omfanget: Jeg testede kun den enkelte side via /v1/scrape. Jeg testede ikke /v1/crawl, som er den multi-side crawler, der gennemgår et helt site. Det er en separat funktion med egne fejlsituationer, og jeg vil ikke påstå, at den virker, når jeg ikke har kørt den.
JavaScript-sider: Den medfølgende browser gør sig fortjent til sin container
En statisk side er den nemme case. Det sværere spørgsmål for enhver scraper er, hvad der sker, når indholdet først dukker op, efter at JavaScript er kørt — hvilket på det moderne web er det meste af tiden.
Det er her, at playwright-service-containeren holder op med at være overhead og bliver selve pointen. Jeg pegede scraperen mod quotes.toscrape.com/js/, en version af demositet, hvor citaterne renderes i browseren. Hvis Firecrawl bare hentede rå HTML, ville citaterne ikke være der — de eksisterer først, når browseren eksekverer sidens script.
Scrapen kom tilbage med 1.574 tegn Markdown, og Einstein-citatet var med. Det citat er indhold, der først kommer efter JavaScript: dets tilstedeværelse beviser, at playwright-service faktisk renderede siden i en rigtig browsermotor, før teksten blev trukket ud, i stedet for bare at hente den tomme skal før rendering.
Så en af de seks containere er en headless browser, og den gør det arbejde, man ville ansætte den til. Det er den konkrete begrundelse for den tungere arkitektur: Du betaler ikke bare for containere, du betaler for evnen til at renderere JS-tunge sider uden selv at bygge browser-automatiseringen op. For mange virkelige targets er det forskellen mellem brugbart output og tomme div’er.
Når målet er dårligt: Strukturerede fejl, ingen crash
Scrapers bruger overraskende meget tid på ting, der ikke virker — døde hosts, forkerte URL’er, servere der hænger. Hvordan et værktøj fejler, siger næsten lige så meget som, hvordan det lykkes.
Jeg fodrede API’et med en ugyldig host med vilje. Det returnerede en struktureret HTTP 500 og blev ved med at køre — ingen stack trace spyttet tilbage til klienten, ingen container der væltede, ingen proces der hang. Fejlen kom tilbage som et rent svar, som kaldet kan reagere på.
Det er den kedelige, korrekte opførsel, man ønsker sig af noget, der skal ind i en pipeline. En scraper, der panikker på et dårligt target, er en scraper, du ikke kan automatisere omkring. Denne her sendte en fejl tilbage, som du kan fange og komme videre fra. Jeg testede kun ét fejlscenarie, så læs det som “håndterede den ene fejl, jeg smed efter den, korrekt” og ikke som en fuld robusthedsrevision — men den ene datapunkt gav det rigtige resultat.
Opsætningsrealitet: Den tungeste løft i basen
Nu kommer den del, ingen tager screenshots af til launch-tweetet. Firecrawl self-hosted var, uden overdrivelse, den mest omfattende opsætning af alle værktøjerne i dette research-base — og jeg har startet mange af dem.
Seks containere er basisomkostningen. Men jeg ramte også to bump på vejen, og jeg vil være helt præcis om, hvis skyld de var — hvilket i sidste ende ikke var Firecrawls.
Bump nummer ét: build fra source. At bygge images fra source fejlede inde i min colima VM med en containerd-snapshotter-fejl. Det er en kendt, lidt ustabil interaktion mellem buildet og colimas storage-lag — et infrastrukturproblem i mit miljø, ikke en bug i Firecrawl. Compose-filen dokumenterer en alternativ vej: brug de officielle forbyggede ghcr.io/firecrawl/*-images i stedet for at bygge lokalt. Jeg skiftede til dem, og hele stakken kom op uden problemer. Hvis du kører på en standard Docker-daemon i stedet for colima, ser du måske aldrig dette; jeg nævner det som en miljøadvarsel, og at validere contributor-buildet på en ren daemon står på min liste over åbne huller.
Bump nummer to: SSRF-beskyttelsen. Mine første scrapes blev blokeret af Firecrawls beskyttelse mod private IP’er / SSRF. Hvorfor? colimas netværksopsætning mapper offentlige hostnavne til 198.18.x.x-adresser, som ligger i et reserveret område, Firecrawl korrekt opfatter som privat — så sikkerhedslaget gjorde det rigtige og nægtede at hente noget, der lignede et internt mål. For at komme udenom det kun til lokal test satte jeg ALLOW_LOCAL_WEBHOOKS=true.
Den flag ender med at blive copy-pastet ind i produktion og skabe problemer, så vær meget præcis om, hvad det er: SSRF-beskyttelsen er en funktion, ikke en hindring. Det er den, der forhindrer en scraping-tjeneste i at blive narret til at ramme dit interne netværk. Jeg deaktiverede den, fordi en særhed ved colimas DNS fik mine legitime offentlige targets til at ligne private inde i VM’en. Slå ikke SSRF-beskyttelse fra i en rigtig deployment. Hvis du tager én driftsmæssig note med fra denne anmeldelse, så tag den.
Begge bump var helt ærligt artefakter af at køre Docker gennem colima på en laptop — ikke mangler i softwaren. Omvendt er opsætningsvægten i sig selv reel, og den er bevidst en del af Firecrawl. Det her er ikke værktøjet, du vælger, når du vil have et hurtigt lokalt script; det er værktøjet, du sætter op, når du vil have en scraping-tjeneste med rendering, og du er villig til at drive infrastrukturen for det.
Hvad jeg ikke testede, og hvad det ikke gør
Her er, hvad jeg ikke dækkede, og hvad værktøjet ikke giver dig.
Self-hosted har ingen Fire-engine. Firecrawls cloud-produkt inkluderer Fire-engine, dets proprietære anti-block-lag til at komme forbi bot-beskyttelse. Ifølge projektets egen SELF_HOST.md får self-hosted-instanser ikke det. Så hvis du forestiller dig, at self-hosted Firecrawl kan trænge igennem aggressive anti-bot-systemer out of the box, så skal billedet justeres — den mulighed ligger i cloud-niveauet, og den var ikke en del af det, jeg kørte.
Cloud-API’et er ikke testet her. Jeg havde ingen cloud-nøgle, så alt ovenfor handler kun om self-hosted-stakken. Den hostede cloud-tjeneste — med Fire-engine, hostet skalering og AI-funktionerne — er et andet produkt, og jeg vil ikke vurdere dens performance udefra. Betragt enhver påstand om cloud som uden for denne anmeldelses scope.
AI-funktioner kræver en nøgle. Det strukturerede json-outputformat og /extract-endpointet bygger på en LLM, hvilket betyder, at du skal bruge en OpenAI-nøgle eller koble Ollama på. Jeg testede ikke de veje, så /extract og struktureret json-output står også i den utestede kolonne.
Proxies er en detalje, ikke en hovedpointe. Firecrawl understøtter proxy-konfiguration, men jeg nævner det bevidst som en fodnote — det er en indstilling, du kan dreje på, ikke en grund til at vælge værktøjet, og self-hosted mangler stadig cloud-versionens anti-block-lag.
AGPL-3.0 er en reel compliance-beslutning. Den fortjener sin egen sektion.
Licensen: Læs AGPL-3.0, før du shipper
Firecrawl er licenseret under AGPL-3.0. Det er ikke en ligegyldig linje nederst i en README — det er stærk copyleft med en netværksbrugsklausul, og den kan direkte påvirke, om du kan bygge et kommercielt produkt oven på en self-hosted instans.
Kort fortalt: De normale GPL-forpligtelser udløses ved distribution. AGPL går længere — netværksbrugs-bestemmelsen betyder, at hvis du stiller softwarens funktionalitet til rådighed for brugere over et netværk, kan det tælle som den type brug, der udløser krav om kildekodeadgang. Hvis du indlejrer self-hosted Firecrawl i en tjeneste, dine kunder tilgår over internettet, er den klausul helt klart relevant, og “vi distribuerede jo aldrig en binary” er ikke den flugtvej, folk tror, den er.
Jeg er ikke din advokat, og licenstolkning afhænger af præcis, hvordan du deployer. Men for enhver kommerciel anbefaling er AGPL-3.0 et førsteordenshensyn, ikke finstilt tekst. Tag den med den, der ejer licensansvaret i din virksomhed, før du bygger ovenpå det. At nævne det er ikke en kritik af Firecrawl — mange fremragende værktøjer er AGPL — det er bare en kendsgerning, du skal have på bordet tidligt.
Hvor Thunderbits udviklerstack passer ind
Prøv Thunderbit til udtræk af webdata
Hvis dit egentlige mål er “side → LLM-klart Markdown” eller “side → strukturerede data”, og den operationelle pris ved seks containere plus AGPL-spørgsmålet ikke er noget, du har lyst til at eje, så er det præcis det hul, Thunderbit's udviklerstack er bygget til at udfylde. Samme AI-motor som driver vores 100.000+ extension-brugere, eksponeret på tre måder til teknisk arbejde — mens infrastrukturen bliver på vores side af linjen.
- Open API (REST).
POST /distillgør en side til rent, LLM-klart Markdown;POST /extractreturnerer strukturerede data ud fra et JSON Schema du selv definerer. JS-rendering, anti-bot-håndtering og dynamisk indhold klares server-side — ingen browsercontainer, du selv skal drifte. EtrenderMode-flag (none/basic/full) styrer, hvor hårdt der renderes, og batch-endpoints håndterer op til 100 URL’er for distill. - MCP-server. En officiel Model Context Protocol-server, så en AI-agent inde i Claude eller Cursor kan scrape midt i en opgave:
thunderbit_suggest_fieldstil at planlægge et udtræk (gratis),thunderbit_distillfor Markdown,thunderbit_extractfor strukturerede data. Agenten beslutter selv, hvornår data skal hentes, uden at forlade sit miljø. - CLI.
npx -y @thunderbit/thunderbit-clikører scrapes fra terminalen, scripts, CI eller cron — ingen browser, ingen stack at babysitte. Send output direkte videre til andre værktøjer:thunderbit distill "$URL" -f markdown | claude -p "summarise".
Kontrasten til self-hosted Firecrawl er klar. Firecrawl self-hosted giver dig fuld kontrol og fuldt driftsansvar: seks containere, opsætningsvægten, AGPL-betingelserne og ingen Fire-engine til anti-block. Thunderbits API/MCP/CLI bytter den kontrol for en hostet motor, der returnerer skemamatchende struktureret JSON — ikke bare rå Markdown — med containere, anti-bot-laget og copyleft-forpligtelserne løftet væk fra dit bord. Forskellige værktøjer til forskellige behov for infrastruktur.
Her er afvejningen i ét overblik:
| Overvejelse | Firecrawl self-hosted | Thunderbit udviklerstack (API · MCP · CLI) |
|---|---|---|
| Deployment-form | Tjeneste, du driver (6 containere) | Hostet API, du kalder |
| For at komme i gang | docker compose op af en 6-service stack | API-nøgle, derefter kald |
| JS-rendering | Medfølgende playwright-service (du driver den) | Server-side, renderMode-flag |
| Struktureret output | Kræver LLM-nøgle (/extract, json) | POST /extract med JSON Schema |
| Anti-bot-lag | Intet self-hosted (Fire-engine er kun cloud) | Håndteres server-side |
| Licens | AGPL-3.0 (network-use copyleft) | Kommerciel API, ingen copyleft på din kode |
| Bedst når | Du vil have fuld kontrol og selv køre infra | Du vil have Markdown/strukturerede data uden drift |
Ingen af dem er universelt “bedre”. Hvis det at drive platformen er pointen for dig — fuld datakontrol, ingen ekstern afhængighed, og AGPL passer til din situation — så er self-hosted Firecrawl et kompetent og aktivt vedligeholdt valg. Hvis du hellere vil lave et API-kald og slippe for livet med seks containere, så er det præcis Thunderbit-stackens pitch.
Hvem bør faktisk self-hoste Firecrawl
Skær hypen væk, og billedet bliver ret tydeligt at sortere efter behov.
Self-host Firecrawl, hvis du vil have fuld kontrol over din scraping-infrastruktur, du er komfortabel med at drifte Redis / RabbitMQ / Postgres / FoundationDB i produktion, dine renderingsbehov retfærdiggør playwright-service-containeren, og AGPL-3.0 fungerer for den måde, du deployer på. Kernefunktionaliteten er reel: Jeg fik rent, struktureret, LLM-klart Markdown ud af både en statisk og en JavaScript-renderet side, og hele stakken kørte på forbyggede images.
Kig andre steder hen, hvis du vil have et hurtigt lokalt script (det her er den tungeste opsætning i basen, punktum), du har brug for cloud-niveau anti-block uden selv at drifte det (self-hosted har ingen Fire-engine), eller AGPLs network-use-klausul støder sammen med dine kommercielle planer. For “jeg skal bare have Markdown eller strukturerede data fra en URL, uden drift”-scenariet dækker en hostet API som Thunderbits /distill og /extract det samme område uden containere.
Min foreløbige vurdering: stærk kerne, tung driftsforpligtelse og en licens, du skal have clearet, før du bygger kommercielt. Den fortjener sin plads hos teams, der vil eje hele pipelinen — og den kræver en del af alle andre. Jeg vender tilbage til den, når jeg har kørt /v1/crawl, testet /extract med en LLM-nøgle og valideret build fra source på en daemon uden colima; det er de åbne spørgsmål mellem denne version og den endelige dom.
Prøv Thunderbit til udtræk af webdata Get Started Free
Ofte stillede spørgsmål
Er self-hosted Firecrawl det samme som cloud-versionen?
Nej. Self-hosted giver dig den centrale scrape-til-Markdown-motor og JavaScript-rendering via den medfølgende playwright-service, men det inkluderer ikke Fire-engine, cloud-produktets proprietære anti-block-lag. AI-funktioner som /extract-endpointet og json-output kræver også din egen LLM-nøgle (OpenAI eller Ollama). I denne anmeldelse testede jeg kun self-hosted-stakken; cloud-API’et lå uden for scope.
Hvor mange containere kræver self-hosted Firecrawl egentlig? Seks: api, playwright-service, redis, rabbitmq, nuq-postgres og foundationdb. Det er en fuld servicestack, ikke en enkelt binary — og derfor var det også den tungeste opsætning af alle værktøjerne i dette research-base. Planlæg efter den driftsmæssige belastning ved at køre message broker, cache og database-infrastruktur, ikke bare et script.
Kan Firecrawl håndtere JavaScript-tunge sider, når den er self-hosted? Ja, i min test. Den medfølgende playwright-service renderer sider i en rigtig browsermotor, før der trækkes data ud. Jeg bekræftede det på quotes.toscrape.com/js/, hvor Einstein-citatet — indhold, som kun findes efter JavaScript kører — dukkede op i det returnerede Markdown. Det er netop derfor, at en af de seks containere er en headless browser.
Påvirker AGPL-3.0-licensen kommerciel brug? Det kan den, og du bør behandle det som et centralt spørgsmål. AGPL-3.0 er stærk copyleft med en netværksbrugsklausul, hvilket betyder, at hvis du stiller softwarens funktionalitet til rådighed for brugere over et netværk, kan det udløse krav om adgang til kildekoden — selv hvis du aldrig distribuerer en binary. Hvis du planlægger at bygge et kommercielt produkt på en self-hosted instans, så tal med den person i din virksomhed, der håndterer licenser, før du går videre. Denne anmeldelse gør opmærksom på licensen; det er ikke juridisk rådgivning.
Hvad er forskellen mellem Firecrawl og Thunderbits udviklerværktøjer?
Firecrawl self-hosted er en tjeneste, du driver — seks containere, du selv kører, med AGPL-3.0-vilkår og ingen indbygget anti-block-lag. Thunderbits udviklerstack (Open API, MCP-server, CLI) er en hostet motor, du kalder: POST /distill for Markdown, POST /extract for JSON-Schema-strukturerede data, med JS-rendering og anti-bot-håndtering server-side og ingen copyleft-forpligtelse på din egen kode. Firecrawl passer til teams, der vil have fuld kontrol over infrastrukturen; Thunderbit passer til dem, der vil have outputtet uden driftsbyrden.
