One engine for several web data jobs
fastCRW bundles five related operations: scrape one page, crawl a bounded site, map its URLs, search the web, and extract fields into structured output. Results can include markdown, HTML, links, screenshots, or schema-shaped JSON. Applications can call the REST API through Python or TypeScript SDKs, while the CLI handles direct jobs. A compatibility layer gives Firecrawl users a less disruptive trial path.
The MCP server is more than a badge on the README. Its installer detects supported AI tools and adds both the server and a CRW skill. The repository contains Claude Code material, including a plugin marketplace entry and a web-scraping guide. That makes fastCRW relevant to developers who want an agent to gather current pages without manually copying content into the prompt. It also raises the usual MCP question: which sites, private networks, and credentials should the agent be allowed to reach?
The project offers a managed API and a local service. Cloud users receive managed proxies, JavaScript rendering, search, and scaling. Local users keep data and network access under their control, but must choose renderers, search, authentication, proxies, and capacity. The README explicitly says capabilities and response shapes can differ between deployments. Check the capabilities endpoint before assuming code tested against the hosted service will behave the same on your server.
The compact binary has an operations bill
A Rust binary is an appealing base for this workload. It can keep the HTTP and orchestration layer small, and fastCRW includes a Dockerfile and Compose setup for teams that prefer containers. The repository also ships SDKs rather than forcing every client to hand-roll request polling and result parsing. Crawl jobs, extraction jobs, and browser processes still consume resources according to the sites and concurrency involved, regardless of how small the idle service looks.
Rendering is where the tidy story gets messy. Ordinary HTML can take a cheap path. JavaScript-heavy pages may need Lightpanda or Chromium, and protected pages can require proxies or still refuse to cooperate. Open issue #189 documents a CARFAX report that returns a browser-not-supported shell because of client-side bot detection. The issue says changing the user agent did not solve it, and even real headless Chromium remained blocked. Teams buying this for protected targets should treat a sample-domain bakeoff as mandatory.
Geography adds another constraint. An open design issue says callers currently choose a proxy exit country explicitly, while locale and timezone signals may not match that country. The document discusses possible inference and retry work, but labels it research and phases rather than shipped behavior. If regional storefronts or geo-restricted pages matter, pass the country deliberately and inspect the returned content. A successful HTTP status alone does not prove that the desired regional page was captured.
What happened when we ran it
Our lab cloned commit 4d4d9fc into an unprivileged Debian container with 3 CPUs, 8 GB of RAM, no secrets, and Node 22. The checkout contained 797 files, about 111,403 lines of source, and occupied 14.8 MB. It had a Dockerfile, a Compose file, a tests directory, and 18 CI workflow files.
The npm install succeeded in 11 seconds. It added one package, used 1 MB on disk, and npm audit reported zero known vulnerabilities across all severity levels. The top-level package file contains a single markdown-processing dependency, which explains the small result. This measurement should not be mistaken for installing and exercising the complete Rust service.
There was no npm build script or target, so the lab skipped the build. There was also no npm test script or target, so tests were skipped. The repository clearly contains Rust crates and tests, and its contributor guide points to Make targets, but our sandbox measurement did not run them. We therefore have no lab evidence about Rust compilation, crawler correctness, browser teardown, or container startup from this run.
Evidence, licensing, and maintenance
fastCRW publishes a benchmark document, its harness, and saved results comparing its scraper with Firecrawl and Crawl4AI on a public dataset. We did not reproduce that benchmark, so its results remain the project's measurements. Use your own domain mix too: public datasets rarely mirror the anti-bot systems, document types, and regional pages that make scraping expensive.
Licensing deserves an early conversation. The engine and MCP server are AGPL-3.0, while the Python and TypeScript SDKs are MIT. The README offers a contact for embedding licensing. Internal network use, a modified hosted service, and distribution can create different obligations, so teams shipping a proprietary product should have counsel review the intended architecture before it hardens around the API.
Maintenance is current. The repository was pushed on August 21, 2026, and release 0.31.0 was published three days earlier. That release added search controls and MCP registration work, then fixed scraping cases involving origin error pages, registrar parking pages, PDF handling, and renderer errors. The 14 open items include issues and pull requests. Recent pull requests cover dependencies, MCP documentation, and the next release.
The fix list is encouraging because it names real failure modes, though it also shows how much page classification a crawler must get right. One open request asks /map to include sitemap file URLs, which it currently omits. If sitemap discovery is part of an indexing workflow, compensate for that gap or wait for the behavior to land.
Who should choose it
Choose fastCRW when you want a compact, self-hostable web data API, need MCP access for Claude Code or another agent, or want to test Firecrawl-compatible calls against a different engine. Its deployment choices and disclosed benchmark method make evaluation straightforward.
Walk away if protected sites must always render, if local and cloud behavior must match without capability checks, or if AGPL terms do not suit the product. Run a trial list drawn from your actual workload, including blocked pages, PDFs, JavaScript applications, and regional sites. The result quality on those URLs matters more than a clean quickstart.