Firecrawl Self-Hosted Rust Crate — Two Paths in 2026

TL;DR — pick your path before the matrix

This page exists because the query firecrawl self-hosted rust crate mixes two intents:

• Path 1 — you want a Rust client against a self-hosted Firecrawl server. The official firecrawl crate is the documented path; the exact constructor (e.g. FirecrawlApp::new_selfhosted) and its arguments shifted between v1 and v2 of the SDK, so pin a version and verify the signature against your stack. You still run the Firecrawl Docker stack (Postgres + Redis + workers).
• Path 2 — you want a Rust server without the Firecrawl Docker stack. That's fastCRW — single statically-linked binary, ~6.6 MB idle RAM, ~85ms cold start, Firecrawl-compatible on the /scrape, /crawl, /map, /search overlap surface.

The two paths are not mutually exclusive: you can also point the official firecrawl crate at a fastCRW instance via the same new_selfhosted constructor, since fastCRW exposes Firecrawl-compatible endpoints.

Path 1 — official firecrawl crate against self-hosted Firecrawl

The firecrawl crate is published on crates.io. Per docs.firecrawl.dev/sdks/rust, the self-host constructor is:

use firecrawl::FirecrawlApp;

let client = FirecrawlApp::new_selfhosted("http://localhost:3002", Some("your-api-key"))?;

To get a Firecrawl server running locally, follow SELF_HOST.md. The stack uses Docker Compose with these services:

• API workers (TypeScript)
• Postgres (job/state)
• Redis (queue)
• SearXNG (optional, for /v1/search self-host)

The Cloud-only Firecrawl features (Fire-engine proprietary anti-bot, /v1/agent Spark models, /v1/deep-research) do not work in the self-host stack — those require Firecrawl Cloud.

Verify the SDK version you pin. The Firecrawl Rust SDK has a v1/v2 split and the constructor surface has shifted between releases — recent v2 endpoints (/v1/parse rolled out April 2026; /v1/agent is Cloud-only) lag the crate. Before you ship, lock the crate version in Cargo.toml, check the constructor signature in that version against your stack, and run a CI demo against a self-hosted Firecrawl deployment. If your team can't stand up the Firecrawl Docker stack in CI, Path 2 (fastCRW) is the lower-friction option.

Path 2 — fastCRW: single Rust binary, Firecrawl-compatible

fastCRW is a Rust-native web scraping and search server. It exposes Firecrawl-compatible REST endpoints on the overlap surface so existing Firecrawl client code (including the official firecrawl Rust crate's new_selfhosted constructor) calls fastCRW after a base-URL swap. Most callers need only minor adjustments — response field names and error envelopes have small divergences (see the matrix below), and /extract users must port to /v1/scrape with formats: ["json"].

docker compose up

Or as a single container without Compose:

docker run -p 3000:3000 ghcr.io/us/crw

Memory baseline: ~6.6 MB idle. Cold start: ~85ms. Docker image: ~8 MB. No Postgres, no Redis, no separate workers.

You can keep using the official firecrawl crate against fastCRW:

use firecrawl::FirecrawlApp;

let client = FirecrawlApp::new_selfhosted("http://localhost:3002", Some("your-key"))?;
let result = client.scrape_url("https://example.com", None).await?;

…or call fastCRW's HTTP API directly with reqwest:

use reqwest::Client;
use serde_json::json;

let response = Client::new()
    .post("http://localhost:3002/v1/scrape")
    .bearer_auth("your-key")
    .json(&json!({
        "url": "https://example.com",
        "formats": ["markdown"],
    }))
    .send()
    .await?
    .json::<serde_json::Value>()
    .await?;

Capability matrix excerpt

The full matrix is in COMPATIBILITY-firecrawl.md. Headline rows:

Capability	Firecrawl Cloud	Firecrawl self-host	fastCRW
/v1/scrape (single URL → markdown/html)	✅	✅	✅
/v1/crawl (multi-page)	✅	✅	✅
/v1/map (URL discovery)	✅	✅	✅
/v1/search	✅	⚠️ (no Fire-engine)	✅ (SearXNG-backed)
/v1/extract (LLM extraction)	✅ standalone route	⚠️ requires LLM key	⚠️ via /v1/scrape formats: ["json"] (single-URL only)
/v1/deep-research	✅	❌	❌
/v1/agent (Spark models)	✅	❌	❌
Fire-engine (proprietary anti-bot)	✅	❌	❌
Single-binary self-host	❌ (Compose stack)	❌	✅

Honest divergences:

• No standalone /v1/extract in fastCRW. Schema-based extraction is on /v1/scrape with formats: ["json"]. Multi-URL batched /extract (a Firecrawl Cloud feature) is not matched.
• No deep research / agent endpoints. Those are Firecrawl Cloud-only.
• No Fire-engine. For cloudflare-protected JS-heavy SPAs, Firecrawl Cloud is the stronger choice.
• Response field-name divergence on a few metadata keys and on error envelope wording — see the matrix for row-level diff.

Where Firecrawl Cloud is still the right call

Neither Path 1 (self-hosted Firecrawl) nor Path 2 (fastCRW) replaces Firecrawl Cloud for these use cases:

• Fire-engine anti-bot. Cloudflare-protected SPAs and JS-heavy sites with active anti-bot systems benefit from Firecrawl's proprietary Fire-engine layer. Self-host doesn't ship it; fastCRW doesn't either.
• /v1/agent and /v1/deep-research. Cloud-only endpoints powered by Firecrawl's Spark models. Not in the self-host stack, not in fastCRW.
• Multi-URL batched /v1/extract. Firecrawl's /extract accepts an array of URLs in one request. fastCRW exposes single-URL extraction only (via /v1/scrape with formats: ["json"]); batching is on the caller side.
• Hosted dashboard, billing, and team management. If you don't want to operate any infrastructure, Firecrawl Cloud's managed surface is the lowest-friction path.

If any of those are central to your workload, stop here and stay on Firecrawl Cloud. This page is not trying to convert that audience.

How to choose

• You want the official Firecrawl client API surface and don't mind running the Firecrawl Docker stack → Path 1.
• You want a single Rust binary you can drop into a server, with the same client code you'd use against Firecrawl → Path 2.
• You need /extract for one URL at a time → either path; on Path 2, swap to /v1/scrape formats: ["json"].
• You need /deep-research, multi-URL /extract, /v1/agent, or Fire-engine → stay on Firecrawl Cloud.

Recommended evaluation flow

1. Skim the Firecrawl ↔ fastCRW capability matrix — confirm your needs land on the overlap surface.
2. Spin up fastCRW: docker compose up and curl the scrape docs.
3. If you're already on the official firecrawl crate, point FirecrawlApp::new_selfhosted at your fastCRW instance and re-run your tests. Field-name divergences will show up there.
4. If you need the Cloud-only Firecrawl surface (/agent, /deep-research, Fire-engine), this page is not the right answer for you — keep the Firecrawl Cloud account.
5. For the broader fastCRW comparison (not Rust-specific), see Firecrawl alternative.

Related

• Firecrawl alternative — the broader brand-comparison page (not Rust-specific).
• How to self-host the Firecrawl API — Path 1 how-to walkthrough (running the Firecrawl Docker stack itself).
• fastCRW search docs — what /v1/search looks like on fastCRW.