The problem, in one sentence
You want a scraping and search API you can drop into existing Firecrawl code, but you don't want to run a five-container stack — or pay per request for content you could pull on your own hardware.
That is the whole reason CRW exists. Firecrawl is a genuinely good product and the engineering behind it is solid — lovely engineering, honestly — but it is built to be run by Firecrawl, and the hosted meter and the self-hosted footprint both reflect that. CRW takes the opposite bet: one small Rust binary you own, an AGPL-3.0 engine you can self-host for the cost of your own server, and a request/response shape close enough to Firecrawl's that most callers change a base URL and nothing else.
This post is a head-to-head, backed by the numbers from Firecrawl's own benchmark: local/open footprint, plus accuracy and median latency.
What you're actually deploying
Start with the thing you have to operate, because that is where the difference is most physical. These are structural facts, not benchmark claims (source: the README §"Structural footprint").
- CRW ships as a single ~8 MB binary. Firecrawl's stack is roughly 2–3 GB total across its images.
- CRW runs in one container (plus an optional sidecar). Firecrawl runs five.
- The default Compose file ships LightPanda as the browser; a heavier Chrome variant is opt-in (~500 MB image, ~1 GB resident when you enable it).
For idle resource use, the engineering write-up cites CRW holding ~50 MB RAM idle on a $5 VPS (source: the how-we-built-fastCRW post's title/description), against a Crawl4AI/Playwright-style baseline it describes as 300 MB+ idle RAM and ~200–300 MB per worker. We're deliberately not quoting other RAM figures here — those are the ones we've verified.
The practical read: CRW fits on the cheapest box you have lying around, and there is exactly one process to babysit. If your reason for looking at a Firecrawl alternative is "I don't want to run a small Kubernetes cluster to scrape some pages," this is the headline.
The API is close to a drop-in
CRW speaks a Firecrawl-compatible API. In most codebases the migration is the base URL and your key:
curl -X POST https://your-crw-host/v1/scrape \
-H "Authorization: Bearer $CRW_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"url": "https://example.com/article",
"formats": ["markdown", "html"]
}'
// TypeScript — the only change from a Firecrawl call is usually the base URL
const res = await fetch("https://your-crw-host/v1/scrape", {
method: "POST",
headers: {
Authorization: `Bearer ${process.env.CRW_API_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify({ url, formats: ["markdown"] }),
});
const { data } = await res.json();
crawl, search, and map follow the same shape. Structured extraction is available by asking for formats: ["json"].
Two things worth knowing before you migrate:
- There is minor divergence in some response fields and the error envelope versus Firecrawl. Close, not byte-identical — check anything that parses error bodies.
- Requests are stateless — there's no persistent session and no WebSocket/SSE crawl-progress stream, so long crawls are polled rather than streamed.
For scrape / crawl / search / map / extract / research, it's usually a drop-in.
Accuracy: the benchmark we lead with
Here's the part that matters more than footprint for most people: does it actually get the content?
On Firecrawl's public scrape-content-dataset-v1 (1,000 URLs, 819 labeled), diagnose_3way.py, single run 3,000 requests, 2026-05-08, CRW came out highest on truth-recall:
- Truth-recall (of 819 labeled URLs): fastCRW 63.74% (522) · Crawl4AI 59.95% (491) · Firecrawl 56.04% (459).
That's +3.79 pp over Crawl4AI and +7.70 pp over Firecrawl on the labeled set — running against a dataset Firecrawl published. Truth-recall is the share of labeled URLs where the run returned the correct content, so this is the closest thing to "did the scraper actually do its job." All three engines threw zero errors across the 3,000 requests in the run.
Latency: median and fast mode
Same benchmark run. We publish the full percentile split rather than a single average — averaging hides exactly the thing you need to see here. On the median request, CRW is the fastest of the three — 1914 ms, effectively tied with Crawl4AI two milliseconds away, and comfortably ahead of Firecrawl's 2305 ms.
The default mode trades some tail latency for recall: on a hard URL where the cheap renderer comes back thin, CRW falls back to a Chrome-stealth render to recover content the others gave up on, which is a big part of how it wins truth-recall above. For latency-critical workloads, CRW's fast mode skips that escalation and posts a p90 of 4348 ms — the lowest of the three — at 91.8% scrape success of reachable URLs (source: the how-we-built-fastCRW post's FAQ). Pick the mode that matches whether you're optimizing for coverage or for tail latency.
Search is a separate story (and a strong one)
CRW also does web search, and it's worth being precise: this benchmark measures search only, not scrape — different harness, different thing.
Over a 100-query benchmark across 10 categories, benchmarks/triple-bench.ts, single point-in-time run:
- Average latency: fastCRW 880 ms · Firecrawl 954 ms · Tavily 2,000 ms.
- Median latency: fastCRW 785 ms · Firecrawl 932 ms · Tavily 1,724 ms.
- P95 latency: fastCRW 1,433 ms · Firecrawl 1,343 ms · Tavily 3,534 ms.
- Latency wins: fastCRW 73/100 · Firecrawl 25/100 · Tavily 2/100.
- Success rate: 100% · 100% · 100%.
The frozen way to cite it: fastCRW search averaged 880 ms over a 100-query benchmark; 73 of 100 latency wins, and all three engines succeeded on every query.
Cost, and the self-host escape hatch
This is the other reason people go looking for a Firecrawl alternative: the meter.
CRW's engine is AGPL-3.0. Self-host it and scraping costs $0 per 1,000 scrapes — you pay for your server, nothing else. For comparison, Firecrawl's hosted pricing works out to $0.83–5.33 per 1,000 scrapes across its tiers (source: marketing/competitor-prices.lock.md, verified 2026-05-18). On a single ~8 MB binary that idles around 50 MB of RAM, "run it yourself" is a real option, not a theoretical one.
If you'd rather use the hosted CRW plans, credits are deliberately simple:
- scrape — 1 credit, on any renderer (auto / http / lightpanda / chrome). Chrome no longer costs extra; it's a flat 1 as of 2026-06-24.
- crawl — 1 per page · search — 1 per query · map — 1 · browse (an MCP session) — 1 per session.
- Structured extract / any request with
formats: ["json"]— 1 scrape credit plus the LLM cost for that page, billed as usage-metered LLM credits.
For the tier prices and included credits, see the live /pricing page — self-hosting the AGPL-3.0 engine remains free regardless of which hosted tier you'd otherwise be on.
On the LLM-backed features (search answer/summarize and JSON extraction): managed LLM usage is metered in credits based on usage. Those features are available on paid plans only — the free tier returns a 402 rather than calling a model. There's no bring-your-own-key path; it's the managed path or self-host the engine and wire your own.
What's different day-to-day
Document handling. CRW auto-detects PDF URLs and extracts text server-side via a built-in parser — point /v1/scrape at a PDF and it comes back as markdown/text like any other page.
Anti-bot and rendering. CRW ships built-in anti-bot in the open core — realistic user agents, header mimicry, cookies, sensible delays, 12-signal block detection, and residential-proxy rotation via the proxy field — alongside an automatic JS-rendering escalation ladder (HTTP → LightPanda → Chrome → proxied Chrome) that recovers thin or blocked pages without extra configuration.
{
"url": "https://protected.example.com",
"formats": ["markdown"],
"proxy": "http://user:pass@your-residential-proxy:port"
}
Statelessness and streaming. No persistent sessions, no WebSocket/SSE crawl-progress stream — you poll crawl status. The LLM features are managed-only on paid plans, with the free tier returning 402. robots.txt is respected by default.
Who should pick which
- Pick Firecrawl if streamed crawl progress over WebSocket/SSE is a hard requirement, and you're happy to run the five-container stack or pay the hosted meter.
- Pick CRW if you want to own the thing: one ~8 MB binary, ~50 MB idle RAM, a self-hostable AGPL-3.0 engine at $0 per 1,000 scrapes, a Firecrawl-compatible API for scrape/crawl/search/map/extract/research, built-in anti-bot and PDF parsing, top-of-three truth-recall on Firecrawl's own dataset, and the fastest median request in that run.
Most teams evaluating a Firecrawl alternative aren't choosing on a single axis. They're weighing "how much do I want to operate" against "how good is the content" against "what does it cost at my volume." CRW's answer is: very little to operate, highest recall on the shared benchmark, free if you self-host. Now you can make that call with the actual numbers.