De fleste plasserer Firecrawl i samme bås som scraping-bibliotekene — altså den gjengen som tenker «pip install, skriv et skript, så er du i mål». Det er en ganske feil måte å se det på, og forskjellen betyr noe før du skriver én eneste kommando. Firecrawl self-hosted er ikke et bibliotek du importerer; det er en tjeneste du drifter, og for å få den opp må du faktisk kjøre seks Docker-containere som snakker sammen.
Jeg kjørte den self-hostede stakken på en Mac (arm64, Docker via colima) uten noen sky-nøkkel, pekte /v1/scrape-endepunktet mot et par demo-nettsider som er greie å scrape, og fulgte med på hva som kom tilbake. Kortversjonen: kjerne-løftet holdt — en side inn, rent LLM-klart Markdown ut — men oppsettet var det tyngste av alle verktøyene jeg har testet i dette research-grunnlaget. Dette er et foreløpig innblikk, ikke en endelig vurdering, og jeg skal være tydelig på hva jeg testet og hva jeg lot være.
Firecrawl er en tjeneste, ikke et bibliotek
Her er den mentale modellen du bør rette opp først. Scraping-verktøyene de fleste utviklere strekker seg etter, er biblioteker: du legger til en avhengighet, kaller en funksjon, og får HTML eller parsede data tilbake i din egen prosess. Firecrawl self-hosted er noe annet. Det er en kjørende plattform med sitt eget API, og du snakker med den over HTTP.
Den offisielle beskrivelsen er «API-et for å søke, scrape og samhandle med weben i stor skala», og produktformen er akkurat det — sider inn, rent Markdown eller strukturert data ut. Når du self-hoster, kobler du deg ikke til Firecrawl som et bibliotek. Du starter en docker compose-stakk og treffer et endepunkt, på samme måte som du ville gjort mot en intern mikrotjeneste.
Stakken jeg kjørte bestod av seks tjenester:
- api — HTTP-flaten du faktisk kaller
- playwright-service — en headless nettleser for JavaScript-rendering
- redis — kø og cache
- rabbitmq — meldingsbroker
- nuq-postgres — en Postgres-variant for jobbstatistikk
- foundationdb — distribuert nøkkel-verdi-lagring
Dette er en skikkelig backend, ikke et hjelpeskript. Redis, RabbitMQ, Postgres og FoundationDB er alle tung infrastruktur i seg selv. Gevinsten er at Firecrawl håndterer de rotete delene av scraping — kølegging, rendering, retries — bak ett API-kall. Prisen er at du nå drifter disse seks containerne. Ha den avveiningen i bakhodet; den går igjen gjennom hele denne gjennomgangen.
Til referanse testet jeg mot firecrawl-py 4.32.0 og firecrawl-js 4.30.0 SDK-ene, og hentet det offisielle forhåndsbygde bildet ghcr.io/firecrawl/firecrawl:latest den 2026-07-09. Repoet lå rundt 148k stjerner på det tidspunktet (regn det som metadata, ikke en kvalitetskarakter), under en AGPL-3.0-lisens — en detalj jeg kommer tilbake til, fordi den endrer regnestykket for kommersiell bruk.
Kjernetesten: En side blir til rent Markdown
Hele poenget med Firecrawl er å gjøre en nettside om til Markdown som en LLM faktisk kan lese. Så det var det første jeg sjekket.
Jeg pekte /v1/scrape mot books.toscrape.com, en statisk katalog som er laget nettopp for scraping-øving. Resultatet: 9 222 tegn med rent, LLM-klart Markdown, med sidetitelen All products | Books to Scrape korrekt tolket. Ikke rå HTML dumpet inn i en streng — strukturert Markdown, med overskrifter, lenker og bildereferanser intakt. Slike resultater kan du i praksis legge rett inn i en retrieval-pipeline eller gi til en modell uten en ekstra oppryddingsrunde.
Dette er Firecrawls sterkeste kort, og den selvhostede utgaven leverte uten noe drama. Hvis jobben din er «gi meg det lesbare innholdet på denne siden som Markdown», kom en statisk side tilbake akkurat som lovet. Det er en genuint nyttig byggestein, og det er grunnen til at verktøyet har det ryktet det har.
Verdt å være presis på omfanget: Jeg testet den ene-sides /v1/scrape-flyten. Jeg testet ikke /v1/crawl, den fler-sidige crawleren som vandrer gjennom et helt nettsted. Det er en egen funksjon med egne feilsituasjoner, og jeg skal ikke påstå at den fungerer når jeg ikke kjørte den.
JavaScript-sider: Den medfølgende nettleseren fortjener containeren sin
En statisk side er den enkle varianten. Den vanskelige delen for enhver scraper er hva som skjer når innholdet først dukker opp etter at JavaScript er kjørt — som på moderne web i de fleste tilfeller er akkurat det som skjer.
Her slutter playwright-service-containeren å være overhead og blir poenget. Jeg pekte scraperen mot quotes.toscrape.com/js/, en variant av demosiden der sitatene rendres på klientsiden. Hvis Firecrawl bare hadde hentet rå HTML, ville sitatene ikke vært der — de eksisterer ikke før nettleseren kjører sidens script.
Scrapen kom tilbake med 1 574 tegn Markdown, og Einstein-sitatet var med. Det sitatet er innhold som først finnes etter JavaScript-kjøring: at det er der, viser at playwright-service faktisk rendret siden i en ekte nettlesermotor før teksten ble ekstrahert, i stedet for å hente den tomme forhåndsrendrede rammen.
Så én av de seks containerne er en headless nettleser, og den gjør jobben du ville leid den inn for. Det er den konkrete begrunnelsen for den tyngre arkitekturen: du betaler ikke bare for containere, du betaler for muligheten til å rendere JS-tunge sider uten å sette opp egen nettleserautomatisering. For mange virkelige mål er det forskjellen mellom brukbart resultat og tomme div-er.
Når målet er dårlig: Strukturerte feil, ingen krasj
Scrapere bruker overraskende mye av livet sitt på ting som ikke fungerer — døde verter, feilskrevne URL-er, servere som henger. Hvordan et verktøy feiler, sier nesten like mye som hvordan det lykkes.
Jeg sendte bevisst et ugyldig hostnavn til API-et. Det returnerte en strukturert HTTP 500 og fortsatte å kjøre — ingen stack trace spydde ut til klienten, ingen container velte, ingen fastlåst prosess. Feilen kom tilbake som et rent svar som kallet kan håndtere videre.
Det er den kjedelige, riktige oppførselen du vil ha fra noe som skal inn i en pipeline. En scraper som panikker på et dårlig mål, er en scraper du ikke kan automatisere rundt. Denne ga tilbake en feil du kan fange og gå videre fra. Jeg testet bare ett feilstilfelle, så les dette som «håndterte den ene feilen jeg kastet på den korrekt», ikke som en fullstendig robusthetsrevisjon — men den ene datapunkten ga riktig resultat.
Oppsettet i praksis: Tyngste løft i basen
Nå kommer delen ingen tar skjermbilde av til lanseringstweeten. Firecrawl self-hosted var, uten overdrivelse, det mest omfattende oppsettet av alle verktøyene i dette research-grunnlaget — og jeg har satt opp mange.
Seks containere er grunnkostnaden. Men jeg støtte også på to problemer underveis, og jeg vil være helt presis på hvem som hadde skylden — ikke Firecrawl, viste det seg.
Problem én: bygging fra kildekode. Å bygge bildene fra kildekode feilet inne i colima-VM-en min på en containerd snapshotter-feil. Det er en kjent ustabil kombinasjon mellom build-prosessen og colimas lagringslag — et infrastrukturhikke i mitt miljø, ikke en bug i Firecrawl. Compose-filen dokumenterer et alternativ: bruk de offisielle forhåndsbygde ghcr.io/firecrawl/*-bildene i stedet for å bygge lokalt. Jeg byttet til dem, og hele stakken kom opp rent. Hvis du bruker en standard Docker-daemon i stedet for colima, er det mulig du aldri ser dette i det hele tatt; jeg nevner det som et miljøforbehold, og å validere bidragsbygget på en ren daemon står på listen min over åpne punkter.
Problem to: SSRF-vernet. De første scrapes ble blokkert av Firecrawls private-IP / SSRF-beskyttelse. Hvorfor? colima-nettverket mapper offentlige hostnavn til 198.18.x.x-adresser, som ligger i et reservert område Firecrawl korrekt tolker som privat — så sikkerhetslaget gjorde jobben sin og nektet å hente det som så ut som et internt mål. For å komme rundt dette kun for lokal testing satte jeg ALLOW_LOCAL_WEBHOOKS=true.
Det flagget blir ofte kopiert inn i produksjon og skaper trøbbel, så vær presis på hva det er: SSRF-vernet er en funksjon, ikke et hinder. Det er det som hindrer en scraping-tjeneste i å bli lurt til å treffe ditt interne nettverk. Jeg skrudde det av fordi en særegenhet i colimas DNS fikk legitime offentlige mål til å se private ut inne i VM-en. Du må ikke slå av SSRF-beskyttelse i en reell produksjon. Hvis du tar med deg bare ett driftsnotat fra denne gjennomgangen, så ta med det.
Begge problemene var rett og slett artefakter av å kjøre Docker via colima på en laptop — ikke feil i programvaren. På den andre siden er selve oppsettsvekten reell, og den er Firecrawls egen ved design. Dette er ikke verktøyet du velger når du vil ha et raskt lokalt skript; det er verktøyet du setter opp når du vil ha en scraping-tjeneste med renderingsevne og er villig til å drifte infrastruktur for å få det.
Hva jeg ikke testet, og hva det ikke gjør
Her er det jeg ikke dekket, og det verktøyet ikke gir deg.
Self-hosted har ingen Fire-engine. Firecrawls skyprodukt inkluderer Fire-engine, den proprietære anti-blokk-lagen for å komme forbi bot-beskyttelse. Ifølge prosjektets egen SELF_HOST.md får ikke self-hosted-installasjoner dette. Så hvis du ser for deg at self-hosted Firecrawl skal trenge gjennom aggressive anti-bot-systemer rett ut av boksen, bør du justere bildet — den funksjonen ligger i skyversjonen, og den var ikke en del av det jeg kjørte.
Sky-API-et er ikke testet her. Jeg hadde ingen sky-nøkkel, så alt over gjelder kun den self-hostede stakken. Den administrerte skytjenesten — med Fire-engine, hostet skalering og AI-funksjonene — er et annet produkt, og jeg kommer ikke til å beskrive ytelsen utenfra. Regn enhver påstand om skyen som utenfor denne gjennomgangens omfang.
AI-funksjoner krever nøkkel. json-formatet for strukturert output og /extract-endepunktet er avhengige av en LLM, som betyr at du må legge inn en OpenAI-nøkkel eller koble til Ollama. Jeg testet ikke disse løypene, så /extract og strukturert json-output havner også i den uprøvde kolonnen.
Proxies er et forbehold, ikke en hovedoverskrift. Firecrawl støtter proxy-oppsett, men jeg nevner det bevisst som en fotnote — det er en justering du kan gjøre, ikke en grunn til å velge verktøyet, og self-hosted mangler fortsatt skyens anti-blokk-lag uansett.
AGPL-3.0 er et reelt compliance-valg. Den fortjener sin egen del.
Lisensen: Les AGPL-3.0 før du shipper
Firecrawl er lisensiert under AGPL-3.0. Det er ikke en ubetydelig linje nederst i en README — det er sterk copyleft med en klausul om nettverksbruk, og det kan direkte påvirke om du kan bygge et kommersielt produkt oppå en self-hosted-instans.
Kortversjonen: vanlige forpliktelser under GPL utløses ved distribusjon. AGPL går lenger — nettverksbruksbestemmelsen betyr at det å tilby programvarens funksjoner til brukere over et nettverk kan regnes som den typen bruk som utløser krav om å gjøre kildekoden tilgjengelig. Hvis du bygger inn self-hosted Firecrawl i en tjeneste kundene dine bruker over internett, er den klausulen helt relevant, og «vi distribuerte jo aldri en binær» er ikke smutthullet folk ofte tror.
Jeg er ikke advokaten din, og lisensfortolkning avhenger av nøyaktig hvordan du deployer. Men for enhver kommersiell anbefaling er AGPL-3.0 et førsteordens hensyn, ikke småskrift. Involver den som eier lisensspørsmålene i selskapet ditt før du bygger på det. Dette er ikke en kritikk av Firecrawl — mange utmerkede verktøy er AGPL — det er bare et faktum du må ha på bordet tidlig.
Hvor Thunderbits utviklerstakk passer inn
Prøv Thunderbit for uttrekking av webdata
Hvis det faktiske målet ditt er «side → LLM-klart Markdown» eller «side → strukturert data», og du ikke ønsker å eie den operative kostnaden med seks containere og AGPL-spørsmålet, er det nettopp dette Thunderbit-utviklerstakken er laget for. Samme AI-motor som ligger bak våre 100 000+ utvidelsesbrukere, eksponert på tre måter for teknisk arbeid — mens infrastrukturen blir på vår side av streken.
- Åpent API (REST).
POST /distillgjør en side om til rent, LLM-klart Markdown;POST /extractreturnerer strukturert data mot et JSON Schema du definerer. JS-rendering, anti-bot-håndtering og dynamisk innhold håndteres på serversiden — ingen nettlesercontainer du må drifte. EnrenderMode-bryter (none/basic/full) styrer hvor hardt den rendrer, og batch-endepunkter håndterer opptil 100 URL-er for distill. - MCP-server. En offisiell Model Context Protocol-server, slik at en AI-agent i Claude eller Cursor kan scrape midt i en oppgave:
thunderbit_suggest_fieldsfor å planlegge en uttrekking (gratis),thunderbit_distillfor Markdown,thunderbit_extractfor strukturert data. Agenten bestemmer når den skal hente data uten å forlate miljøet sitt. - CLI.
npx -y @thunderbit/thunderbit-clikjører scraping fra terminalen, skript, CI eller cron — ingen nettleser, ingen stakk å passe på. Kjør det rett videre til andre verktøy:thunderbit distill "$URL" -f markdown | claude -p "summarise".
Kontrasten til self-hosted Firecrawl er tydelig. Firecrawl self-hosted gir deg full kontroll og fullt operativt eierskap: seks containere, oppsettvekten, AGPL-vilkårene og ingen Fire-engine for anti-blokk. Thunderbits API/MCP/CLI bytter bort den kontrollen mot en hostet motor som returnerer strukturert JSON som matcher skjema — ikke bare rå Markdown — samtidig som containere, anti-bot-lag og copyleft-forpliktelser forsvinner fra din side. Ulike verktøy for ulike behov for infrastruktur.
Her er avveiningen i én oversikt:
| Vurdering | Firecrawl self-hosted | Thunderbit utviklerstakk (API · MCP · CLI) |
|---|---|---|
| Utrullingsform | Tjeneste du drifter (6 containere) | Hostet API du kaller |
| For å komme i gang | docker compose opp en 6-tjenesters stakk | API-nøkkel, så request |
| JS-rendering | Medfølgende playwright-service (du drifter den) | På serversiden, renderMode-flagg |
| Strukturert output | Krever LLM-nøkkel (/extract, json) | POST /extract med JSON Schema |
| Anti-bot-lag | Ingen i self-hosted (Fire-engine er kun i skyen) | Håndteres på serversiden |
| Lisens | AGPL-3.0 (network-use copyleft) | Kommersiell API, ingen copyleft på koden din |
| Best når | Du vil ha full kontroll og vil drifte infrastruktur | Du vil ha Markdown/strukturert data uten drift |
Ingen av dem er universelt «bedre». Hvis det å drifte plattformen er poenget for deg — full datakontroll, ingen ekstern avhengighet, og AGPL passer situasjonen din — er self-hosted Firecrawl et kapabelt og aktivt vedlikeholdt valg. Hvis du heller vil gjøre et API-kall og slippe seks-container-livet, er det akkurat det Thunderbit-stakken tilbyr.
Hvem bør faktisk self-hoste Firecrawl
Tar du bort hypen, blir bildet ganske tydelig å sortere etter behov.
Self-host Firecrawl hvis du vil ha full kontroll over scraping-infrastrukturen din, du er komfortabel med å drifte Redis / RabbitMQ / Postgres / FoundationDB i produksjon, rendering-behovene dine rettferdiggjør playwright-service-containeren, og AGPL-3.0 fungerer for måten du deployer på. Kjernefunksjonen er reell: Jeg fikk rent, strukturert, LLM-klart Markdown ut av både en statisk og en JS-rendret side, og hele stakken kjørte på forhåndsbygde bilder.
Se andre steder hvis du vil ha et raskt lokalt skript (dette er det tyngste oppsettet i basen, punktum), du trenger skyklasse anti-blokk uten å drifte det selv (self-hosted har ingen Fire-engine), eller AGPLs nettverksbruksklausul krasjer med de kommersielle planene dine. For «jeg trenger bare Markdown eller strukturert data fra en URL, uten drift»-caset dekker en hostet API som Thunderbits /distill og /extract det samme området uten containerne.
Min foreløpige vurdering: sterk kjerne, tung operasjonell forpliktelse, og en lisens du må avklare før du bygger kommersielt. Den fortjener plassen sin for team som vil eie hele pipelinen — og den krever mye av alle andre. Jeg kommer tilbake til dette når jeg har kjørt /v1/crawl, testet /extract med en LLM-nøkkel og validert bygg fra kildekode på en daemon som ikke er colima; det er de åpne spørsmålene mellom denne og en endelig konklusjon.
Prøv Thunderbit for uttrekking av webdata Get Started Free
Vanlige spørsmål
Er self-hosted Firecrawl det samme som skyversjonen?
Nei. Self-hosted gir deg kjerne-motoren for scraping til Markdown og JavaScript-rendering via den medfølgende playwright-service, men den inkluderer ikke Fire-engine, den proprietære anti-blokk-lagen i skyproduktet. AI-funksjoner som /extract-endepunktet og json-output krever også din egen LLM-nøkkel (OpenAI eller Ollama). I denne gjennomgangen testet jeg bare den self-hostede stakken; sky-API-et var utenfor omfanget.
Hvor mange containere trenger egentlig self-hosted Firecrawl? Seks: api, playwright-service, redis, rabbitmq, nuq-postgres og foundationdb. Det er en full tjenestestakk, ikke en enkelt binær — og det er derfor det var det tyngste oppsettet av alle verktøyene i dette research-grunnlaget. Regn med operativ overhead ved å drifte meldingsbroker, cache og databaser, ikke bare et skript.
Kan Firecrawl håndtere JavaScript-tunge sider når det er self-hosted? Ja, i min testing. Den medfølgende playwright-service rendrer sider i en ekte nettlesermotor før uttrekk. Jeg bekreftet dette på quotes.toscrape.com/js/, der Einstein-sitatet — innhold som først finnes etter at JavaScript kjører — dukket opp i det returnerte Markdown-et. Nettopp denne renderingsevnen er grunnen til at én av de seks containerne er en headless nettleser.
Påvirker AGPL-3.0-lisensen kommersiell bruk? Det kan den, og du bør behandle det som et spørsmål av første orden. AGPL-3.0 er sterk copyleft med en klausul om nettverksbruk, som betyr at det å tilby programvarens funksjoner til brukere over et nettverk kan utløse krav om å gjøre kildekoden tilgjengelig — selv om du aldri distribuerer en binær. Hvis du planlegger å bygge et kommersielt produkt på en self-hosted instans, snakk med den som håndterer lisensspørsmål i selskapet ditt før du forplikter deg. Denne gjennomgangen flagger lisensen; det er ikke juridisk rådgivning.
Hva er forskjellen mellom Firecrawl og Thunderbits utviklerverktøy?
Firecrawl self-hosted er en tjeneste du drifter — seks containere du kjører selv, med AGPL-3.0-vilkår og ingen innebygd anti-blokk-lag. Thunderbits utviklerstakk (Open API, MCP-server, CLI) er en hostet motor du kaller: POST /distill for Markdown, POST /extract for JSON-Schema-strukturert data, med JS-rendering og anti-bot-håndtering på serversiden og ingen copyleft-forpliktelse på din egen kode. Firecrawl passer team som vil ha full infrastrukturkontroll; Thunderbit passer dem som vil ha resultatet uten driftsbyrden.
