By the fastCRW team · Comparison post · Verify Zyte pricing/features independently.
Disclosure: Written by the fastCRW team; fastCRW is in the comparison. Zyte's products and pricing evolve — confirm on zyte.com before deciding.
Short answer
Zyte (formerly Scrapinghub, the company behind Scrapy) sells a managed scraping platform: the Zyte API with automatic data extraction, a smart proxy/ban-handling layer, and Scrapy Cloud for hosting Scrapy spiders. It is strong, mature, and especially good at e-commerce extraction. The most common reason to look for a Zyte alternative is that you want LLM-ready output, flat predictable pricing, and the option to self-host the engine for free — none of which is Zyte's model. That is fastCRW's lane.
What Zyte is good at
- Automatic extraction. Zyte's auto-extraction can pull structured product/article/job data without per-site selectors, and it adapts when layouts change. For large-scale e-commerce catalogs this is a genuine strength.
- Scrapy heritage. If your team already runs Scrapy spiders, Scrapy Cloud is a natural managed home with deployment, scheduling, and monitoring built around the framework you know.
- Smart proxy/ban handling. Zyte's proxy layer handles bans and retries transparently for hard targets.
Why teams want a Zyte alternative
- Not LLM-output-native. Zyte's automatic extraction is structured-record-oriented (products, articles), not "clean markdown for a context window." RAG and agent pipelines want clean full-page markdown, which is fastCRW's default.
- Per-request pricing at scale. Zyte API bills per request with variables for the features you use; for continuous AI scraping, forecasting is harder than a flat per-page rate.
- Cloud-only. No free, unlimited, self-hostable engine. Data flows through Zyte's platform.
- Scrapy lock-in for the Cloud path. Scrapy Cloud's value assumes you build and maintain Scrapy spiders — a Python framework commitment plus per-site parser maintenance.
- Narrow beyond e-commerce. Auto-extraction shines on product/article shapes; general "any URL → clean content for an LLM" is not the design center.
Comparison table
| Dimension | Zyte | fastCRW |
|---|---|---|
| Core | Auto-extraction API + Scrapy Cloud + proxy | Open-core scrape/crawl/map/search API |
| Output | Structured records (product/article) | Clean markdown / HTML / JSON schema |
| LLM/RAG-native | Indirect | ✅ By default |
| Self-host | ❌ Cloud-only | ✅ AGPL-3.0, ~6 MB binary |
| Pricing | Per-request, feature-variable | Flat: 1 credit = 1 page |
| Best at | E-commerce auto-extraction at scale | General AI web-data, crawl, search |
| Framework lock-in | Scrapy (for Scrapy Cloud path) | None (language-agnostic REST) |
| MCP / agents | Not native | ✅ Built-in MCP |
| Firecrawl-compatible | ❌ | ✅ |
Where fastCRW wins
- LLM-ready by default. Markdown / structured JSON via schema with no per-site parser code. Define what you want semantically; it survives redesigns.
- Flat, predictable pricing. 1 credit = 1 page, no per-feature request multipliers.
- Free self-host. AGPL-3.0, ~6 MB Rust binary, unlimited self-host, data never leaves your infra.
- No framework commitment. Language-agnostic REST + MCP; you do not have to live in Scrapy.
- Speed and footprint. Lower-latency, local-first engine with a small single binary; runs on a $5 VPS. See the public benchmark at /benchmarks for the full latency distribution.
Honesty note: fastCRW Cloud's free tier is a one-time lifetime 500 credits (not monthly). The standout free path is unlimited free self-host of the engine.
Migration: Zyte to fastCRW
- Classify usage. Auto-extraction calls, raw fetch calls, Scrapy Cloud spiders, proxy-only usage.
- Map endpoints. Raw fetch → fastCRW
/v1/scrape(markdown). Structured extraction →/v1/scrapewithformats: ["json"]+ a JSON schema describing fields. Site traversal →/v1/crawl+/v1/map. - Port Scrapy spiders incrementally. You can keep Scrapy for orchestration and call fastCRW for clean content inside the spider, then retire spiders that were only doing fetch+parse.
- Pilot on the highest-volume route, compare output and cost on real traffic.
- Self-host if data residency matters; otherwise base-URL swap to fastCRW Cloud.
Structured extraction without per-site parsers
from firecrawl import FirecrawlApp
app = FirecrawlApp(api_key="key", api_url="http://localhost:3000")
res = app.scrape_url("https://shop.example.com/p/123", params={
"formats": ["json"],
"jsonOptions": {"schema": {
"type": "object",
"properties": {"title": {"type": "string"}, "price": {"type": "string"}},
"required": ["title", "price"],
}},
})
print(res["json"])
Why the Scrapy heritage cuts both ways
Zyte's biggest asset is also its biggest constraint. Being the company behind Scrapy means deep crawling expertise, a mature managed Scrapy Cloud, and battle-tested ban handling. But it also means the platform's center of gravity is the Scrapy programming model: spiders, item pipelines, settings, and the per-site parser maintenance that comes with selector-based extraction. If your team lives in Scrapy and intends to keep doing so, that gravity is a feature. If you are building AI pipelines and would rather not maintain a spider fleet, it is friction — you are adopting a framework commitment to get a data outcome.
fastCRW deliberately has no framework. It is a language-agnostic REST surface plus a built-in MCP server. You call it from Python, Node, Go, a shell script, or directly from an AI agent's tool loop, and you get clean markdown or schema JSON back. There is no spider lifecycle, no reactor to operate, no per-site parser to keep alive against redesigns. For teams whose job is feeding LLMs, removing the framework is removing a category of ongoing work, not just swapping a vendor.
Layout resilience: schema-driven extraction
fastCRW takes a schema-driven route: you describe the fields semantically and the LLM-powered engine extracts them. In practice, semantic schema extraction is far more redesign-resilient than hand-written CSS/XPath selectors, because you are asking for "the price" rather than pointing at a DOM node that a layout change can silently break.
Cost predictability and data locality
Two structural factors usually tip AI teams toward fastCRW regardless of the extraction debate. First, predictability: per-request, feature-variable pricing makes "what does this monthly workload cost?" a modeling exercise, while flat 1-credit-per-page makes it arithmetic. Second, locality: Zyte is cloud-only, so target URLs and scraped content traverse a third party. Self-hosting fastCRW's AGPL-3.0 binary keeps both inside your network with no per-request fee at all. For regulated, security-conscious, or competitively sensitive work, that is not a preference — it is frequently the hard requirement that ends the evaluation.
Getting started
docker run -p 3000:3000 ghcr.io/us/crw:latest
Free self-host (AGPL-3.0) or fastCRW Cloud (one-time 500 free credits, no card). GitHub.
