Useimmat ihmiset niputtavat Firecrawl samaan koriin kuin scrapauslibit — siihen porukkaan, jonka kanssa teet pip installin, kirjoitat pienen skriptin ja homma on siinä. Tuo ajattelutapa on kuitenkin väärä, ja ero on tärkeä jo ennen kuin kirjoitat yhtään komentoa. Firecrawl itse isännöitynä ei ole kirjasto, jonka importtaat, vaan palvelu, jota ylläpidät. Sen pyörittäminen tarkoittaa kuuden Docker-kontin ajamista, jotka keskustelevat keskenään.
Ajoin itse isännöidyn pinon Macilla (arm64, Docker coliman kautta) ilman pilviavainta, osoitin sen /v1/scrape-päätepisteen muutamaan scrapausystävälliseen demosivustoon ja katsoin, mitä takaisin tuli. Lyhyt versio: ydintä koskeva lupaus piti kutinsa — sivu meni sisään, siisti LLM-valmis Markdown tuli ulos — mutta käyttöönotto oli raskain kaikista tähän tutkimuspohjaan ajamistani työkaluista. Tämä on alustava arvio, ei lopullinen tuomio, ja kerron tarkasti, mitä testasin ja mitä en.
Firecrawl on palvelu, ei kirjasto
Tässä on ajattelumalli, joka kannattaa korjata ensin. Useimmat kehittäjät suhtautuvat scrapaustyökaluihin kirjastoina: lisäät riippuvuuden, kutsut funktiota ja saat HTML:n tai parsitun datan takaisin omaan prosessiisi. Itse isännöity Firecrawl on eri maata. Se on käynnissä oleva alusta omalla API:llaan, johon otetaan yhteyttä HTTP:n yli.
Virallinen kuvaus kuuluu suunnilleen näin: "API webin hakemiseen, scrapaamiseen ja käyttämiseen skaalassa", ja tuotteen muoto vastaa sitä hyvin — sivut sisään, siisti Markdown tai jäsennelty data ulos. Kun isännöit sen itse, et linkitä Firecrawlta omaan koodiisi. Sen sijaan nostat docker compose -pinon ylös ja kutsut päätepistettä aivan kuten mitä tahansa sisäistä mikropalvelua.
Pino, jota ajoin, sisälsi kuusi palvelua:
- api — varsinainen HTTP-rajapinta, jota kutsut
- playwright-service — headless-selain JavaScript-renderöintiä varten
- redis — jono ja välimuisti
- rabbitmq — viestinvälitys
- nuq-postgres — Postgres-variantti työtilan tilalle
- foundationdb — hajautettu avain–arvo-tallennus
Tämä on oikea taustajärjestelmä, ei mikään apuskripti. Redis, RabbitMQ, Postgres ja FoundationDB ovat kaikki jo sellaisenaan tuotantotason infraa. Vastineeksi Firecrawl hoitaa scrapaamisen sotkuiset osat — jonotuksen, renderöinnin, uudelleenyritykset — yhden API-kutsun taakse piilotettuna. Hinta on se, että sinä operoit nyt noita kuutta konttia. Pidä tämä vaihtokauppa mielessä; se kulkee läpi koko tämän arvion.
Vertailun vuoksi testasin firecrawl-py 4.32.0 ja firecrawl-js 4.30.0 -SDK:illa ja vedin virallisen valmiiksi rakennetun ghcr.io/firecrawl/firecrawl:latest -kuvan 2026-07-09. Repossa oli tuolloin noin 148 000 tähteä (pidetään tämä metatietona, ei laatupisteinä), ja se on AGPL-3.0 -lisenssin alla — yksityiskohta, johon palaan, koska se muuttaa kaupallisen käytön laskelmaa.
Ydintesti: sivusta tulee siisti Markdown
Koko Firecrawl’n olemassaolon syy on muuntaa verkkosivu Markdowniksi, jota LLM oikeasti pystyy lukemaan. Se oli siis ensimmäinen asia, jonka tarkistin.
Kohdistin /v1/scrape-kutsun sivustoon books.toscrape.com, joka on staattinen katalogi, tehty nimenomaan scrapausharjoitteluun. Tulos: 9 222 merkkiä siistiä, LLM-valmista Markdownia, ja sivun otsikko All products | Books to Scrape parsettiin oikein. Ei raakaa HTML:ää yhtenä pitkänä merkkijonona — vaan jäsenneltyä Markdownia, jossa otsikot, linkit ja kuvaviitteet säilyivät. Sellaista outputia, jonka voi laittaa suoraan hakupohjaiseen putkeen tai syöttää mallille ilman ylimääräistä siivousta.
Tämä on Firecrawl’n päävahvuus, ja itse isännöitynä se toimi ilman draamaa. Jos työsi on "anna minulle tämän sivun luettava sisältö Markdownina", staattinen sivu tuli takaisin juuri niin kuin luvattiin. Se on aidosti hyödyllinen peruspalikka, ja juuri siksi työkalu on kerännyt oman seuraajakuntansa.
On kuitenkin syytä olla tarkka rajauksesta: testasin vain yhden sivun /v1/scrape-polkua. En testannut /v1/crawl-ominaisuutta, eli monisivuista crawleria, joka käy koko sivuston läpi. Se on eri kyvykkyys omine vikamuotoineen, enkä aio väittää sen toimivan, kun en sitä ajanut.
JavaScript-sivut: mukana tuleva selain ansaitsee konttinsa
Staattinen sivu on helppo tapaus. Vaikeampi kysymys mille tahansa scraperille on, mitä tapahtuu, kun sisältö ilmestyy vasta JavaScriptin ajon jälkeen — mikä nykypäivän webissä on useimmiten tilanne.
Tässä kohtaa tuo playwright-service-kontti lakkaa olemasta ylimääräinen kulu ja alkaa olla koko homman pointti. Kohdistin scraperin osoitteeseen quotes.toscrape.com/js/, eli demosivuston versioon, joka renderöi sitaatit client-puolella. Jos Firecrawl vain hakisi raakaa HTML:ää, sitaatteja ei olisi mukana — niitä ei ole olemassa ennen kuin selain suorittaa sivun skriptin.
Scrape palautti 1 574 merkkiä Markdownia, ja Einstein-sitaatti oli mukana. Kyseinen sitaatti on JavaScriptin jälkeistä sisältöä: sen läsnäolo todistaa, että playwright-service oikeasti renderöi sivun selaimen moottorissa ennen tekstin poimimista, eikä vain nappaa tyhjää, ennen renderöintiä olevaa kuorta.
Eli yksi kuudesta kontista on headless-selain, ja se tekee juuri sen työn, jota varten se on olemassa. Tämä on konkreettinen peruste raskaammalle arkkitehtuurille: et maksa vain konteista, vaan siitä, että voit renderöidä JS-raskaita sivuja ilman, että joudut itse rakentamaan selainautomaatiota. Monissa oikeissa kohteissa juuri tämä erottaa käyttökelpoisen tuloksen tyhjistä div-elementeistä.
Kun kohde on huono: jäsennelty virhe, ei kaatumista
Scraperit viettävät yllättävän paljon aikaa kohdistettuna asioihin, jotka eivät toimi — kuolleisiin hosteihin, kirjoitusvirheellisiin URL-osoitteisiin, palvelimiin, jotka katkaisevat yhteyden. Se, miten työkalu epäonnistuu, kertoo siitä yhtä paljon kuin se, miten se onnistuu.
Syötin API:lle tarkoituksella väärän hostin. Se palautti jäsennellyn HTTP 500 -vastauksen ja jatkoi toimintaansa — ei stack tracea asiakkaalle, ei konttia nurin, ei jumittunutta prosessia. Virhe tuli takaisin siistinä vastauksena, jonka kutsuja voi käsitellä haarautumalla.
Se on tylsä, mutta oikea tapa toimia silloin, kun scraperia ajetaan putkessa. Scraperi, joka menee sekaisin huonosta kohteesta, on scraperi, jota et voi automatisoida luotettavasti. Tämä yksilö palautti virheen, jonka voi napata kiinni ja jatkaa eteenpäin. Testasin vain yhden virhetapauksen, joten lue tämä muodossa "käsitteli oikein sen yhden epäonnistumisen, jonka sille heitin", ei kattavana resilienttiyden auditointina — mutta tämä yksi datapiste oli oikea tulos.
Käyttöönoton todellisuus: raskain nosto tässä pohjassa
Nyt siihen osaan, jota kukaan ei screenshottaa lanseeraustviittiä varten. Firecrawl itse isännöitynä oli, liioittelematta, tämän tutkimuspohjan työläin käyttöönotto — ja olen käynnistänyt niitä monta.
Kuusi konttia on lähtökohtainen hinta. Mutta törmäsin matkalla myös kahteen mutkaan, ja haluan olla täsmällinen siitä, kenen syytä ne olivat — kävi ilmi, ettei Firecrawl’n.
Mutka yksi: lähdekoodista rakentaminen. Kuvien rakentaminen lähteestä epäonnistui colima-virtuaalikoneessani containerd snapshotter -virheen takia. Se on tunnettu, välillä oikukas yhteys buildin ja coliman tallennuskerroksen välillä — infrastruktuurihäiriö minun ympäristössäni, ei bugi Firecrawl’ssa. Compose-tiedosto dokumentoi vaihtoehdon: käytä virallisia valmiiksi rakennettuja ghcr.io/firecrawl/* -kuvia paikallisen rakentamisen sijaan. Vaihdoin niihin, ja koko pino nousi ylös puhtaasti. Jos käytät tavallista Docker-daemonia etkä colimaa, et välttämättä koskaan kohtaa tätä; merkitsen sen ympäristöön liittyväksi huomautukseksi, ja contributor-rakennuksen varmistaminen puhtaalla daemonilla on omalla to do -listallani.
Mutka kaksi: SSRF-suoja. Ensimmäiset scrape-kutsuni estyivät Firecrawl’n yksityisen IP:n / SSRF-suojauksen takia. Miksi? coliman verkotus mapittaa julkiset hostinimet osoitteisiin 198.18.x.x, jotka kuuluvat varattuun osoiteavaruuteen ja joita Firecrawl perustellusti käsittelee yksityisenä — eli sen turvakerros teki juuri työnsä ja kieltäytyi hakemasta sellaista, mikä näytti sisäiseltä kohteelta. Kiertääkseni tämän vain paikallista testausta varten asetin muuttujan ALLOW_LOCAL_WEBHOOKS=true.
Tuo lippu kopioidaan tuotantoon ja siitä seuraa ongelmia, joten ole tarkka siitä, mitä se tekee: SSRF-suoja on ominaisuus, ei este. Se estää scrapauspalvelua joutumasta huijatuksi hakemaan sisäverkkoasi. Poistin sen käytöstä, koska coliman DNS:n erikoisuus sai omat lailliset julkiset kohteeni näyttämään VM:n sisällä yksityisiltä. Älä kytke SSRF-suojausta pois oikeassa tuotannossa. Jos otat tästä arvostelusta yhden operatiivisen neuvon, ota juuri tämä.
Molemmat mutkat olivat, suoraan sanottuna, coliman kautta laptopilla ajetun Dockerin sivuvaikutuksia — eivät ohjelmiston vikoja. Toisaalta käyttöönoton painavuus on todellinen, ja se on Firecrawl’n suunniteltu ominaisuus. Tämä ei ole työkalu, johon tartut, kun haluat nopean paikallisskriptin; tämä on työkalu, jonka nostat pystyyn, kun haluat renderöintikykyisen scrapauspalvelun ja olet valmis ylläpitämään sitä varten infrastruktuuria.
Mitä en testannut ja mitä tämä ei tee
Tässä on se, mitä en kattanut — ja mitä työkalu ei sinulle tarjoa.
Itse isännöidystä versiosta puuttuu Fire-engine. Firecrawl’n pilvituote sisältää Fire-engine:n, sen omistusoikeudellisen anti-block-kerroksen, joka kiertää bottipuolustuksia. Projektin oman SELF_HOST.md mukaan itse isännöidyt instanssit eivät saa sitä. Jos siis kuvittelet itse isännöidyn Firecrawl’n murtautuvan aggressiivisten anti-bot-järjestelmien läpi suoraan paketista, kannattaa tarkistaa mielikuva — tuo kyky kuuluu pilvitasoon, eikä se ollut osa sitä, mitä ajoin.
Pilvi-API jäi testaamatta. Minulla ei ollut pilviavainta, joten kaikki yllä oleva koskee vain itse isännöityä pinoa. Hallinnoitu pilvipalvelu — Fire-engine, hostattu skaalautuvuus ja AI-ominaisuudet — on eri tuote, enkä aio kuvata sen suorituskykyä ulkopuolelta käsin. Pidä kaikki pilveen liittyvät väitteet tämän arvion ulkopuolella.
AI-ominaisuudet tarvitsevat avaimen. json-rakenteinen output-muoto ja /extract-päätepiste nojaavat LLM:ään, mikä tarkoittaa joko OpenAI-avaimen tuomista tai Ollama:n kytkemistä mukaan. En käyttänyt näitä polkuja, joten /extract ja rakenteinen json-output kuuluvat myös testaamattomien listalle.
Proxyt ovat huomio, eivät otsikko. Firecrawl tukee proxyn asetusta, mutta mainitsen sen tarkoituksella sivuhuomautuksena — se on säätö, jonka voit kääntää, ei syy valita työkalua, ja itse isännöity versio on silti ilman pilven anti-block-kerrosta.
AGPL-3.0 on oikea compliance-päätös. Tämä ansaitsee oman kappaleensa.
Lisenssi: lue AGPL-3.0 ennen kuin julkaiset mitään
Firecrawl on AGPL-3.0 -lisenssin alla. Se ei ole mikään README:n loppuun heitetty pikkuhuomio — se on vahva copyleft-lisenssi verkonkäyttöehdolla, ja se voi vaikuttaa suoraan siihen, voitko rakentaa kaupallisen tuotteen itse isännöidyn instanssin päälle.
Lyhyesti: tavallisen GPL:n velvoitteet laukeavat jakelusta. AGPL menee pidemmälle — verkonkäyttöä koskeva ehto tarkoittaa, että ohjelmiston toiminnon tarjoaminen käyttäjille verkon yli voi olla sellaista käyttöä, johon liittyy lähdekoodin saatavuusvelvoite. Jos upotat itse isännöidyn Firecrawl’n osaksi palvelua, johon asiakkaasi ottavat yhteyttä internetin yli, tuo kohta on täysin olennainen, eikä "emmehän me koskaan jakaneet binääriä" ole se oikotie, jonka moni kuvittelee sen olevan.
En ole asianajajasi, ja lisenssin tulkinta riippuu tarkasta toteutustavasta. Mutta missä tahansa kaupallisessa suosituksessa AGPL-3.0 on ensisijainen huomio, ei pienellä painettu alaviite. Ota mukaan se henkilö, joka vastaa yrityksesi lisenssiasioista, ennen kuin rakennat tämän päälle. Tämän nostaminen ei ole Firecrawl’n moittimista — monet erinomaiset työkalut ovat AGPL:n alla — vaan fakta, joka pitää olla pöydällä ajoissa.
Mihin Thunderbitin kehittäjäpino sopii
Kokeile Thunderbitiä webdatan poimintaan
Jos todellinen tavoitteesi on "sivu → LLM-valmis Markdown" tai "sivu → jäsennelty data", eikä kuuden kontin operatiivinen vero plus AGPL-kysymys ole jotain, mitä haluat omille harteillesi, juuri tuota aukkoa varten Thunderbitn kehittäjäpino on tehty. Sama AI-moottori, jonka päällä toimii yli 100 000 laajennuskäyttäjää, tarjolla kolmella tavalla tekniseen työhön — niin, että infra pysyy meidän puolellamme rajaa.
- Avoin API (REST).
POST /distillmuuttaa sivun siistiksi, LLM-valmiiksi Markdowniksi;POST /extractpalauttaa jäsennellyn datan määrittelemäsi JSON Scheman perusteella. JavaScript-renderöinti, anti-bot-käsittely ja dynaaminen sisältö hoidetaan palvelinpuolella — sinun ei tarvitse pyörittää selainkonttia itse.renderMode-lippu (none/basic/full) määrää, kuinka perusteellisesti sivu renderöidään, ja eräpäätteet käsittelevät jopa 100 URL-osoitetta distillille. - MCP-palvelin. Virallinen Model Context Protocol -palvelin, joten Claude’n tai Cursorin sisällä toimiva AI-agentti voi scrapeata kesken tehtävän:
thunderbit_suggest_fieldssuunnittelee poiminnan (ilmainen),thunderbit_distilltuottaa Markdownin jathunderbit_extractjäsennellyn datan. Agentti päättää milloin data haetaan, ilman että sen tarvitsee poistua omasta ympäristöstään. - CLI.
npx -y @thunderbit/thunderbit-cliajaa scrapet terminaalista, skripteistä, CI:stä tai cronista — ei selainta, ei pinon vahtimista. Voit putkittaa sen suoraan muihin työkaluihin:thunderbit distill "$URL" -f markdown | claude -p "summarise".
Vertailu itse isännöityyn Firecrawl’hin on selkeä. Firecrawl itse isännöitynä antaa sinulle täyden hallinnan ja täyden operatiivisen vastuun: kuusi konttia, käyttöönoton paino, AGPL-ehdot ja ei Fire-engineä anti-blockia varten. Thunderbitin API/MCP/CLI vaihtaa tuon hallinnan hostattuun moottoriin, joka palauttaa skeemaan sopivaa jäsenneltyä JSONia — ei pelkkää raakaa Markdownia — ja ottaa kontit, anti-bot-kerroksen sekä copyleft-velvoitteet pois omalta lautaseltasi. Eri työkalut eri infrastruktuurinsietokyvylle.
Tässä vaihto yhdellä silmäyksellä:
| Huomio | Firecrawl itse isännöitynä | Thunderbitin kehittäjäpino (API · MCP · CLI) |
|---|---|---|
| Käyttöönoton muoto | Palvelu, jota operoit itse (6 konttia) | Hostattu API, jota kutsut |
| Käynnistys | docker compose kuuden palvelun pinolla | API-avain, sitten pyyntö |
| JS-renderöinti | Mukana tuleva playwright-service (sinä ajat sitä) | Palvelinpuolella, renderMode-lippu |
| Jäsennelty ulostulo | Tarvitsee LLM-avaimen (/extract, json) | POST /extract JSON Scheman kanssa |
| Anti-bot-kerros | Ei itse isännöitynä (Fire-engine on vain pilvessä) | Hoidetaan palvelinpuolella |
| Lisenssi | AGPL-3.0 (verkonkäytön copyleft) | Kaupallinen API, ei copyleftiä omalle koodillesi |
| Paras kun | Haluat täyden hallinnan ja pyörität infrastruktuuria itse | Haluat Markdownia/jäsenneltyä dataa ilman ops-työtä |
Kumpikaan ei ole yleisesti "parempi". Jos alustan pyörittäminen on sinulle osa tavoitetta — täysi datanhallinta, ei ulkoista riippuvuutta ja AGPL sopii tilanteeseesi — itse isännöity Firecrawl on pätevä ja aktiivisesti ylläpidetty valinta. Jos taas haluat mieluummin tehdä API-kutsun ja ohittaa kuuden kontin arjen, Thunderbitin pino on juuri sitä varten.
Kenen kannattaa oikeasti isännöidä Firecrawl itse
Kun hype riisutaan pois, kuva on tarpeeksi selkeä tarpeen mukaan lajiteltavaksi.
Isännöi Firecrawl itse, jos haluat täydellisen hallinnan scrapausinfrastasi, olet valmis operoimaan Redis / RabbitMQ / Postgres / FoundationDB -yhdistelmää tuotannossa, renderöintitarpeesi oikeuttavat playwright-service-kontin ja AGPL-3.0 sopii käyttöösi. Ydinominaisuus on aito: sain siistiä, jäsenneltyä, LLM-valmista Markdownia sekä staattiselta että JavaScriptillä renderöidyltä sivulta, ja koko pino toimi valmiiksi rakennetuilla kuvilla.
Katso muualle, jos haluat nopean paikallisskriptin (tämä on pohjan raskain käyttöönotto, piste), tarvitset pilvitason anti-blockia ilman että ylläpidät sitä itse (itse isännöitynä ei ole Fire-engineä), tai AGPL:n verkonkäyttöehto törmää kaupallisiin suunnitelmiisi. Tapauksessa "tarvitsen vain Markdownia tai jäsenneltyä dataa URL:sta, ilman opsia" hostattu API kuten Thunderbitin /distill ja /extract hoitaa saman alueen ilman konteista tulevaa taakkaa.
Alustava tulkintani: vahva ydin, raskas operatiivinen sitoumus ja lisenssi, joka pitää selvittää ennen kaupallista rakentamista. Se ansaitsee paikkansa tiimeille, jotka haluavat omistaa koko putken — ja se vaatii paljon kaikilta muilta. Palaan tähän, kun olen ajanut /v1/crawl-polun, käyttänyt /extract-toimintoa LLM-avaimella ja varmistanut lähdekoodista rakentamisen ei-colima-daemonissa; nämä ovat avoimet kysymykset tämän ja lopullisen arvion välillä.
Kokeile Thunderbitiä webdatan poimintaan Get Started Free
Usein kysytyt kysymykset
Onko itse isännöity Firecrawl sama kuin pilviversio?
Ei. Itse isännöity versio antaa sinulle ydintoiminnon, eli sivusta Markdowniksi -moottorin, sekä JavaScript-renderöinnin mukana tulevan playwright-service-palvelun kautta, mutta siinä ei ole Fire-engineä, joka on pilvituotteen omistusoikeudellinen anti-block-kerros. AI-ominaisuudet kuten /extract-päätepiste ja json-ulostulo vaativat myös oman LLM-avaimen (OpenAI tai Ollama). Tässä arviossa testasin vain itse isännöityä pinoa; pilvi-API oli rajauksen ulkopuolella.
Kuinka monta konttia itse isännöity Firecrawl oikeasti tarvitsee? Kuusi: api, playwright-service, redis, rabbitmq, nuq-postgres ja foundationdb. Kyseessä on täysi palvelupino, ei yksi binääri — siksi se oli raskain käyttöönotto kaikista tähän tutkimuspohjaan katsomistani työkaluista. Varaudu viestioperaattorin, välimuistin ja tietokanta-infran operointiin, älä vain skriptiin.
Pystyykö Firecrawl itse isännöitynä käsittelemään JavaScript-raskaita sivuja? Kyllä, testissäni pystyi. Mukana tuleva playwright-service renderöi sivut oikeassa selaimen moottorissa ennen poimintaa. Varmistin tämän sivulla quotes.toscrape.com/js/, jossa Einstein-sitaatti — sisältö, joka on olemassa vasta JavaScriptin ajon jälkeen — ilmestyi palautettuun Markdowniin. Juuri tämän renderöintikyvyn takia yksi kuudesta kontista on headless-selain.
Vaikuttaako AGPL-3.0-lisenssi kaupalliseen käyttöön? Voi vaikuttaa, ja sitä kannattaa pitää ensisijaisena kysymyksenä. AGPL-3.0 on vahva copyleft, johon kuuluu verkonkäyttöehto, joten ohjelmiston toiminnon tarjoaminen käyttäjille verkon yli voi tuoda mukanaan lähdekoodin saatavuusvelvoitteita — vaikka et koskaan jakaisi binääriä. Jos aiot rakentaa kaupallisen tuotteen itse isännöidyn instanssin päälle, keskustele yrityksesi lisenssiasioista vastaavan tahon kanssa ennen sitoutumista. Tämä arvio nostaa lisenssin esiin; se ei ole lakineuvontaa.
Mitä eroa on Firecrawl’n ja Thunderbitin kehittäjätyökalujen välillä?
Firecrawl itse isännöitynä on palvelu, jota operoit itse — kuusi konttia, joita pyörität itse, AGPL-3.0-ehdot ja ilman sisäänrakennettua anti-block-kerrosta. Thunderbitin kehittäjäpino (Open API, MCP-palvelin, CLI) on hostattu moottori, jota kutsut: POST /distill Markdownia varten, POST /extract JSON-Schema-jäsenneltyä dataa varten, JavaScript-renderöinti ja anti-bot-käsittely palvelinpuolella eikä copyleft-velvoitetta omalle koodillesi. Firecrawl sopii tiimeille, jotka haluavat täyden infranhallinnan; Thunderbit sopii niille, jotka haluavat lopputuloksen ilman operatiivista kuormaa.
