Short answer: Self-hosted web scraping means running the scraper process on infrastructure you control — usually a single binary, container, or Docker Compose stack — instead of calling a vendor's hosted API. You own the proxy configuration, the browser fleet, the extraction logic, the rate limits, and every byte of fetched HTML.
A SaaS scraper (Firecrawl Cloud, ScrapingBee, Apify) terminates the HTTP request inside the vendor's network. You receive markdown or JSON; the vendor sees the source URL, the response body, and your usage patterns. Self-hosted scraping inverts that boundary: your server makes the outbound fetch, your disk holds the cache, and only you see what was scraped. For regulated workloads (PII, healthcare, internal-only sources), legal teams typically require this posture.
Self-hosting trades vendor lock-in for operational surface. You become responsible for browser updates (Chromium, LightPanda), JS rendering stability, residential or datacenter proxy procurement, robots.txt compliance, retry budgets, and observability. Modern self-hosted stacks ship as a single static binary to keep that surface small — no Redis, no Node sidecar, no Postgres — so the only things to monitor are CPU, RAM, and outbound bandwidth.
fastCRW ships a single Rust binary under AGPL-3.0 — roughly ~50 MB RAM idle (structural footprint per crw-opencore/README.md) — that exposes the same Firecrawl-compatible REST surface as our hosted API: /v1/scrape, /v1/crawl, /v1/map, /v1/search. No auth is required by default in self-hosted mode. See self-hosting and configuration for the full setup.