De flesta placerar Firecrawl i samma fack som scrapingbiblioteken — det där "pip install, skriv ett script, klart"-gänget. Den bilden stämmer inte, och skillnaden spelar roll innan du ens skriver ett enda kommando. Firecrawl self-hosted är inget bibliotek du importerar; det är en tjänst du driver, och att få den i gång betyder att du kör sex Docker-containrar som pratar med varandra.
Jag körde self-hosted-stacken på en Mac (arm64, Docker via colima) utan någon molnnyckel, pekade dess /v1/scrape-endpoint mot ett par demo-sajter som är snälla mot scraping, och såg vad som kom tillbaka. Kort sagt: kärnlöftet höll — en sida gick in, ren LLM-redo Markdown kom ut — men uppsättningen var den tyngsta av alla verktyg jag har testat i den här researchbasen. Det här är en preliminär genomgång, inte ett slutgiltigt betyg, och jag kommer vara tydlig med vad jag testade och inte testade.
Firecrawl är en tjänst, inte ett bibliotek
Här är den mentala modellen som behöver rättas till först. De scrapingverktyg de flesta utvecklare använder är bibliotek: du lägger till ett beroende, anropar en funktion och får tillbaka HTML eller parsad data i din egen process. Firecrawl self-hosted är något annat. Det är en körande plattform med ett eget API, och du pratar med den över HTTP.
Den officiella positioneringen är "the API to search, scrape, and interact with the web at scale", och produktens form är precis det — sidor in, ren Markdown eller strukturerad data ut. När du kör det själv länkar du inte mot Firecrawl. Du startar en docker compose-stack och träffar en endpoint, på samma sätt som du skulle anropa en intern mikrotjänst.
Stacken jag körde bestod av sex tjänster:
- api — HTTP-gränssnittet du faktiskt anropar
- playwright-service — en headless browser för JavaScript-rendering
- redis — kö och cache
- rabbitmq — meddelandebroker
- nuq-postgres — en Postgres-variant för jobbstatus
- foundationdb — distribuerad nyckel-värde-lagring
Det här är en riktig backend, inte ett hjälpskript. Redis, RabbitMQ, Postgres och FoundationDB är alla tung infrastruktur i egen rätt. Vinsten är att Firecrawl sköter de röriga delarna av scraping — köhantering, rendering, retries — bakom ett enda API-anrop. Kostnaden är att du nu också driver de här sex containrarna. Ha den avvägningen i bakhuvudet; den är den röda tråden genom hela den här genomgången.
Som referens testade jag mot firecrawl-py 4.32.0 och firecrawl-js 4.30.0 SDK:erna, och drog den officiella förbyggda ghcr.io/firecrawl/firecrawl:latest-imagen den 2026-07-09. Repo:t låg då på ungefär 148k stjärnor (betrakta det som metadata, inte ett kvalitetsbetyg), under en AGPL-3.0-licens — en detalj jag återkommer till, eftersom den påverkar kalkylen för kommersiell användning.
Kärntestet: en sida blir ren Markdown
Hela poängen med Firecrawl är att förvandla en webbsida till Markdown som en LLM faktiskt kan läsa. Så det var det första jag kollade.
Jag pekade /v1/scrape mot books.toscrape.com, en statisk katalog som byggts just för scrapingövning. Resultatet: 9 222 tecken ren, LLM-redo Markdown, med sidtiteln All products | Books to Scrape korrekt parsad. Inte rå HTML som dumpats i en sträng — utan strukturerad Markdown, med rubriker, länkar och bildreferenser intakta. Precis den typ av output du kan stoppa rakt in i en retrieval pipeline eller mata till en modell utan ett extra rensningssteg.
Det här är Firecrawl på sitt bästa, och self-hosted levererade utan dramatik. Om ditt jobb är "ge mig det läsbara innehållet från den här sidan som Markdown" kom en statisk sida tillbaka exakt som utlovat. Det är en riktigt användbar byggsten, och det är därför verktyget har den följarskara det har.
Värt att vara exakt med omfånget: jag testade den enskilda /v1/scrape-vägen. Jag testade inte /v1/crawl, den fler-sidiga crawl-funktionen som går igenom en hel sajt. Det är en separat förmåga med egna felmoder, och jag tänker inte påstå att den fungerar när jag inte körde den.
JavaScript-sidor: den medföljande browsern förtjänar sin container
En statisk sida är det lätta fallet. Den svårare frågan för alla scrapers är vad som händer när innehållet bara dyker upp efter att JavaScript har körts — vilket på dagens webben är det vanliga.
Det är här playwright-service-containern slutar vara overhead och börjar vara själva poängen. Jag pekade scrapern mot quotes.toscrape.com/js/, en version av demosajten där citaten renderas på klientsidan. Om Firecrawl bara hämtade rå HTML skulle citaten inte finnas där — de existerar inte förrän webbläsaren kör sidans script.
Scrapen kom tillbaka med 1 574 tecken Markdown, och Einstein-citatet fanns med. Det citatet är innehåll efter JavaScript-körning: dess närvaro bevisar att playwright-service faktiskt renderade sidan i en riktig browsermotor innan texten extraherades, i stället för att bara plocka den tomma pre-render-skalet.
Så en av de sex containrarna är en headless browser, och den gör jobbet den är anställd för. Det är den konkreta motiveringen till den tyngre arkitekturen: du betalar inte bara för containrar, utan för förmågan att rendera JS-tunga sidor utan att själv bygga browserautomation. För många verkliga mål är det skillnaden mellan användbar output och tomma div:ar.
När målet är dåligt: strukturerade fel, inget krascha
Scrapers spenderar förvånansvärt mycket tid på att peka mot saker som inte fungerar — döda hosts, felstavade URL:er, servrar som bara hänger sig. Hur ett verktyg misslyckas säger lika mycket som hur det lyckas.
Jag matade medvetet API:t med en ogiltig host. Det svarade med en strukturerad HTTP 500 och fortsatte köra — ingen stack trace spottades ut till klienten, ingen container föll omkull, ingen process låste sig. Felet kom tillbaka som ett rent svar som anroparen kan grena på.
Det är det tråkiga, korrekta beteende du vill ha från något som ska in i en pipeline. En scraper som får panik av ett dåligt mål är en scraper du inte kan automatisera runt. Den här gav tillbaka ett fel du kan fånga upp och gå vidare från. Jag testade bara ett enda felcase, så läs detta som "hanterade den enda feltyp jag kastade på den korrekt", inte som en fullständig robusthetsgranskning — men den ena datapunkten blev rätt.
Installationsverkligheten: den tyngsta lyftet i basen
Nu kommer delen ingen fotar för lanseringstweeten. Firecrawl self-hosted var, utan överdrift, den mest omfattande installationen av alla verktyg i den här researchbasen — och jag har satt upp många.
Sex containrar är grundkostnaden. Men jag stötte också på två hinder på vägen upp, och jag vill vara exakt med vems fel de var — inte Firecrawls, som det visade sig.
Hinder ett: bygget från källkod. Att bygga images från källkod misslyckades i min colima-VM med ett containerd snapshotter-fel. Det är en känd lite instabil kombination mellan bygget och colimas lagringslager — en infrastrukturknack i min miljö, inte en bugg i Firecrawl. compose-filen dokumenterar ett alternativ: använd de officiella förbyggda ghcr.io/firecrawl/*-images i stället för att bygga lokalt. Jag bytte till dem, och hela stacken startade utan problem. Om du kör en vanlig Docker-daemon i stället för colima kanske du aldrig ser detta alls; jag markerar det som en miljöreservation, och att verifiera contributor-bygget på en ren daemon står på min lista över luckor.
Hinder två: SSRF-skyddet. Mina första scrapes blockerades av Firecrawls skydd mot privata IP-adresser / SSRF. Varför? colimas nätverksupplägg mappar publika hostnamn till adresser i 198.18.x.x, vilket är ett reserverat intervall som Firecrawl korrekt behandlar som privat — så dess säkerhetslager gjorde precis sitt jobb och vägrade hämta något som såg ut som ett internt mål. För att kringgå det endast för lokala tester satte jag ALLOW_LOCAL_WEBHOOKS=true.
Den flaggan copy-pastas in i produktion och orsakar incidenter, så var noga med vad den är: SSRF-skyddet är en funktion, inte ett hinder. Det är det som hindrar en scrapingtjänst från att luras att angripa ditt interna nätverk. Jag stängde av det eftersom en egenhet i colimas DNS gjorde att mina legitima publika mål såg privata ut inne i VM:n. Stäng inte av SSRF-skydd i en riktig driftmiljö. Om du tar med dig en enda driftsnotis från den här genomgången, ta med den.
Båda hindren var, för att vara tydlig, artefakter av att köra Docker via colima på en laptop — inte fel i mjukvaran. Å andra sidan är installationsvikten i sig verklig, och den är Firecrawls medvetna design. Det här är inte verktyget du plockar fram när du vill ha ett snabbt lokalt script; det här är verktyget du sätter upp när du vill ha en scrapingtjänst med rendering och du är beredd att drifta infrastruktur för det.
Vad jag inte testade, och vad det inte gör
Här är vad jag inte täckte, och vad verktyget inte ger dig.
Self-hosted har ingen Fire-engine. Firecrawls molnprodukt inkluderar Fire-engine, deras proprietära anti-block-lager för att ta sig förbi bottar och skydd. Enligt projektets egen SELF_HOST.md får self-hosted-instanser inte detta. Så om du föreställer dig att self-hosted Firecrawl utan vidare tar sig igenom aggressiva anti-bot-system, justera bilden — den förmågan finns i molnversionen och ingick inte i det jag körde.
Moln-API:t är inte testat här. Jag hade ingen molnnyckel, så allt ovan gäller bara self-hosted-stacken. Den hanterade molntjänsten — med Fire-engine, hostad skalning och AI-funktionerna — är en annan produkt, och jag tänker inte beskriva dess prestanda från utsidan. Betrakta alla påståenden om molnet som utanför ramen för den här genomgången.
AI-funktioner kräver en nyckel. Det strukturerade json-formatet och /extract-endpointen bygger på en LLM, vilket betyder att du behöver en OpenAI-nyckel eller koppla in Ollama. Jag testade inte de vägarna, så /extract och strukturerad json-output ligger också i den otestade kolumnen.
Proxyar är en brasklapp, inte rubriken. Firecrawl stöder proxykonfiguration, men jag tar med det som en fotnot med flit — det är en ratt du kan vrida på, inte anledningen att välja verktyget, och self-hosted saknar fortfarande molnversionens anti-block-lager.
AGPL-3.0 är ett verkligt licensbeslut. Den här förtjänar ett eget avsnitt.
Licensen: läs AGPL-3.0 innan du släpper något
Firecrawl är licensierat under AGPL-3.0. Det är inte en slängkommentar längst ner i en README — det är stark copyleft med en klausul om nätverksanvändning, och den kan direkt påverka om du kan bygga en kommersiell produkt ovanpå en self-hosted-instans.
Kortversionen: vanliga GPL-krav triggas vid distribution. AGPL går längre — klausulen om nätverksanvändning innebär att om du erbjuder mjukvarans funktion till användare över nätverk kan det räknas som en typ av användning som medför krav på källkodstillgänglighet. Om du bäddar in self-hosted Firecrawl i en tjänst som dina kunder når över internet, är den klausulen helt relevant, och "vi skickade aldrig någon binär" är inte den genväg folk ofta tror att den är.
Jag är inte din jurist, och licenstolkning beror på exakt hur du driftsätter. Men för alla kommersiella rekommendationer är AGPL-3.0 en förstahandsfråga, inte finstilt. Ta med den som ansvarar för licenser på ditt företag innan du bygger på den. Att lyfta detta är inte att racka ner på Firecrawl — många utmärkta verktyg är AGPL — det är bara ett faktum som måste upp på bordet tidigt.
Var Thunderbits utvecklarstack passar in
Testa Thunderbit för webbdataextraktion
Om ditt faktiska mål är "sida → LLM-redo Markdown" eller "sida → strukturerad data", och den operativa sex-container-skatten plus AGPL-frågan inte är något du vill bära själv, är det exakt det glapp Thunderbit-s utvecklarstack är byggd för. Samma AI-motor som våra 100 000+ tilläggsanvändare använder, exponerad på tre sätt för tekniskt arbete — medan infrastrukturen stannar på vår sida av linjen.
- Öppet API (REST).
POST /distillförvandlar en sida till ren, LLM-redo Markdown;POST /extractreturnerar strukturerad data mot ett JSON Schema du själv definierar. JS-rendering, anti-bot-hantering och dynamiskt innehåll hanteras server-side — ingen browsercontainer du behöver drifta. EnrenderMode-flagga (none/basic/full) styr hur hårt den renderar, och batch-endpoints klarar upp till 100 URL:er för distill. - MCP-server. En officiell Model Context Protocol-server, så att en AI-agent i Claude eller Cursor kan scrapa mitt i ett uppdrag:
thunderbit_suggest_fieldsför att planera en extraktion (gratis),thunderbit_distillför Markdown,thunderbit_extractför strukturerad data. Agenten avgör när data ska hämtas utan att lämna sin miljö. - CLI.
npx -y @thunderbit/thunderbit-clikör scraping från terminalen, scripts, CI eller cron — ingen browser, ingen stack att passa upp på. Pipa det direkt in i andra verktyg:thunderbit distill "$URL" -f markdown | claude -p "summarise".
Kontrasten mot self-hosted Firecrawl är tydlig. Firecrawl self-hosted ger dig full kontroll och fullt operativt ansvar: sex containrar, installationsvikten, AGPL-villkoren och ingen Fire-engine för anti-block. Thunderbits API/MCP/CLI byter bort den kontrollen mot en hostad motor som returnerar schemastämd strukturerad JSON — inte bara rå Markdown — medan containrarna, anti-bot-lagret och copyleft-kraven lyfts bort från din tallrik. Olika verktyg för olika aptit på infrastruktur.
Så här ser avvägningen ut i en vy:
| Aspekt | Firecrawl self-hosted | Thunderbit utvecklarstack (API · MCP · CLI) |
|---|---|---|
| Driftsform | Tjänst du driver själv (6 containrar) | Hostat API du anropar |
| För att komma igång | docker compose med en 6-tjänsters stack | API-nyckel, sedan anrop |
| JS-rendering | Inbyggd playwright-service (du driftar den) | Server-side, renderMode-flagga |
| Strukturerad output | Kräver LLM-nyckel (/extract, json) | POST /extract med JSON Schema |
| Anti-bot-lager | Inget i self-hosted (Fire-engine är endast i molnet) | Hanteras server-side |
| Licens | AGPL-3.0 (copyleft vid nätverksanvändning) | Kommersiellt API, ingen copyleft på din kod |
| Bäst när | Du vill ha full kontroll och kan drifta infra | Du vill ha Markdown/strukturerad data utan drift |
Ingen av dem är universellt "bättre." Om det faktiskt är poängen för dig att driva plattformen — full kontroll över data, inget externt beroende och AGPL passar din situation — är self-hosted Firecrawl ett kompetent och aktivt underhållet val. Om du hellre vill göra ett API-anrop och slippa sex-container-livet, är det precis vad Thunderbit-stacken är tänkt för.
Vem bör egentligen self-hosta Firecrawl
Skala bort hypen och bilden blir ganska tydlig.
Self-hosta Firecrawl om du vill ha full kontroll över din scrapinginfrastruktur, du är bekväm med att drifta Redis / RabbitMQ / Postgres / FoundationDB i produktion, dina renderingsbehov motiverar playwright-service-containern, och AGPL-3.0 fungerar för hur du driftsätter. Kärnförmågan är verklig: jag fick ut ren, strukturerad, LLM-redo Markdown från både en statisk och en JS-renderad sida, och hela stacken körde på förbyggda images.
Titta någon annanstans om du vill ha ett snabbt lokalt script (det här är den tyngsta installationen i basen, punkt slut), du behöver anti-block på molnnivå utan att drifta det själv (self-hosted har ingen Fire-engine), eller AGPL:s klausul om nätverksanvändning krockar med dina kommersiella planer. För fallet "jag behöver bara Markdown eller strukturerad data från en URL, utan drift" täcker en hostad API-lösning som Thunderbits /distill och /extract samma område utan containrarna.
Min preliminära bedömning: stark kärna, tung operativ förpliktelse och en licens du måste reda ut innan du bygger kommersiellt. Det förtjänar sin plats hos team som vill äga hela pipelinen — och det kräver mycket av alla andra. Jag kommer återkomma till detta när jag har kört /v1/crawl, testat /extract med en LLM-nyckel och verifierat from-source-bygget på en daemon utan colima; det är de öppna frågorna mellan den här och ett slutomdöme.
Testa Thunderbit för webbdataextraktion Get Started Free
Vanliga frågor
Är Firecrawl self-hosted samma som molnversionen?
Nej. Self-hosted ger dig den centrala scrape-till-Markdown-motorn och JavaScript-rendering via den medföljande playwright-service, men den innehåller inte Fire-engine, molnproduktens proprietära anti-block-lager. AI-funktioner som /extract-endpointen och json-output kräver också en egen LLM-nyckel (OpenAI eller Ollama). I den här genomgången testade jag bara self-hosted-stacken; moln-API:t låg utanför ramen.
Hur många containrar behöver Firecrawl self-hosted egentligen? Sex: api, playwright-service, redis, rabbitmq, nuq-postgres och foundationdb. Det är en full tjänstestack, inte en enda binär — vilket är anledningen till att det blev den tyngsta installationen av alla verktyg i den här researchbasen. Räkna med den operativa kostnaden för att drifta meddelandebroker, cache och databasinfrastruktur, inte bara ett script.
Kan Firecrawl hantera JavaScript-tunga sidor när det körs self-hosted? Ja, i mina tester. Den medföljande playwright-service renderar sidor i en riktig browsermotor innan extraktion. Jag bekräftade det på quotes.toscrape.com/js/, där Einstein-citatet — innehåll som bara finns efter att JavaScript körts — dök upp i den returnerade Markdown:en. Den renderingsförmågan är exakt varför en av de sex containrarna är en headless browser.
Påverkar AGPL-3.0-licensen kommersiell användning? Det kan den göra, och du bör behandla det som en förstahandsfråga. AGPL-3.0 är stark copyleft med en klausul om nätverksanvändning, vilket betyder att när du erbjuder mjukvarans funktion till användare över nätverk kan det medföra krav på källkodstillgänglighet — även om du aldrig distribuerar någon binär. Om du planerar att bygga en kommersiell produkt på en self-hosted-instans, prata med den som hanterar licenser på ditt företag innan du bestämmer dig. Den här genomgången lyfter licensen; det är inte juridisk rådgivning.
Vad är skillnaden mellan Firecrawl och Thunderbits utvecklarverktyg?
Firecrawl self-hosted är en tjänst du själv driver — sex containrar du kör på egen hand, med AGPL-3.0-villkor och inget inbyggt anti-block-lager. Thunderbits utvecklarstack (Open API, MCP-server, CLI) är en hostad motor du anropar: POST /distill för Markdown, POST /extract för JSON Schema-strukturerad data, med JS-rendering och anti-bot-hantering server-side och ingen copyleft-förpliktelse på din egen kod. Firecrawl passar team som vill ha full kontroll över infrastrukturen; Thunderbit passar dem som vill ha outputen utan driftsbördan.
