By the fastCRW team · Competitor pricing characterized qualitatively, fastCRW figures verified 2026-05-18 · fastCRW prices: see /pricing, verify independently before buying.
Disclosure: We build fastCRW. This is a vendor-authored comparison, so weight it accordingly — the worked cost math below runs only on fastCRW's frozen, published credit model, and we keep a "Where Apify genuinely wins" section because a comparison that pretends the competitor has none is useless to you.
How Apify cost stacks up at scale
If you are trying to answer "what will Apify cost at scale" for a data team running Actors at volume, the hard part is not finding a number — it is that there is no single number. Apify's platform bill is composed of several metered dimensions that stack on the same run, and each one moves independently of the page count you actually care about. Understanding that stacking is the whole game when you forecast monthly spend.
The three dimensions teams most often trip over are:
- Compute units (CUs). Actors are billed for the compute they consume — roughly memory allocated multiplied by wall-clock runtime. A heavier headless-browser Actor on a bigger memory setting burns CUs faster than a lightweight HTTP Actor, even when both fetch the same number of pages.
- Proxy traffic. Datacenter and residential proxy usage is metered separately. Residential and other premium proxy classes cost materially more per gigabyte than datacenter, so a switch made to defeat anti-bot defenses quietly changes your unit economics.
- Per-result or Actor-specific charges. Many marketplace Actors layer their own pay-per-result or rental pricing on top of the platform's compute and proxy meters.
None of these is a defect. A general compute platform that runs arbitrary Actors genuinely cannot price like a fixed-shape API, because it does not know in advance what your Actor will do. The trade-off is real: you get a marketplace of thousands of prebuilt scrapers, and in exchange the bill is multi-dimensional. We are characterizing Apify's model qualitatively here — compute-unit, proxy, and per-result meters that stack — not quoting a frozen dollar figure, because their live pricing should be read off their own page, not ours.
The forecastability problem
The reason CU stacking matters for budgeting is that the dimension you can predict (page count) is not the dimension you are billed on (compute time, proxy gigabytes, per-result counts). Two runs that scrape the same 10,000 URLs can produce different bills if one hits more JS-heavy pages, retries more often, or routes more traffic through residential proxies. The cost is a function of execution, not intent.
That is where bills surprise mid-volume teams. A pipeline that looked cheap in a 1,000-page proof of concept can scale super-linearly when:
- A site tightens its anti-bot posture, pushing you from datacenter to residential proxies — the per-gigabyte rate jumps while the page count stays flat.
- Target pages get heavier, so each Actor run holds memory longer and consumes more CUs per page.
- You add a marketplace Actor with its own per-result fee, introducing a fourth meter you now have to model.
To forecast accurately, you have to estimate CU consumption per run, proxy mix, and per-result counts independently, then sum them. That is a legitimately hard modeling exercise, and it is the core of the "Apify cost at scale" question. The alternative is not a cheaper platform — it is a pricing model with fewer moving parts.
fastCRW's single-dimension credit model
fastCRW takes the opposite stance: one dimension, metered per operation, published in a short table. Every number here traces to fastCRW's internal source of recordso you can forecast a monthly bill from page volume alone.
| Operation | Credits |
|---|---|
scrape (any renderer: http / lightpanda / chrome) | 1 |
crawl | 1 per page |
search | 1 per query |
map | 1 |
extract / any request with formats: ["json"] | 1 + LLM token cost (usage-metered) |
There are no separate proxy gigabytes to model, no compute-time meter, and no per-result rental layered on top. JSON extraction is the 1-credit scrape plus the LLM token cost, billed as usage-metered LLM credits in the same currency — not a second subscription. The renderer is chosen automatically (chrome → lightpanda → http fallback), and every renderer — including Chrome — costs the same flat 1 credit.
Concretely, forecasting works like arithmetic. If you scrape 100,000 pages in a month, that is 100,000 credits — regardless of which renderer each page uses, including Chrome. There is no fourth or fifth variable hiding in a proxy line item. For the tier dollar figures behind those credits, see live /pricing — we deliberately do not hard-code the table here so it can never drift out of date.
Honest gap: no Actor marketplace
Here is the trade-off in the other direction, stated plainly. fastCRW is a primitive — a single static Rust binary exposing a Firecrawl-compatible REST surface (/v1/scrape, /v1/crawl, /v1/map, /v1/search) — not a marketplace of prebuilt scrapers. There is no equivalent of Apify's Actor store, no library of site-specific extractors maintained by a community, and no place to rent a turnkey "scrape this exact social network" Actor.
It also lacks some cloud-only specialties worth naming up front: no Fire-engine-class anti-bot, no residential proxy pool, and the engine is stateless per request (no persistent session or login state). If your workload depends on a long-tail site that already has a well-maintained Apify Actor — and building and maintaining your own extractor against that site would cost more engineering time than the stacked CU bill — then Apify's marketplace is genuinely the cheaper path once you price in your own labor. That is a real win for Apify, not a concession we make grudgingly.
Cost at scale: a like-for-like estimate
Because Apify's pricing is multi-dimensional and not S0-locked in our records, we will not invent a head-to-head dollar table. Instead, here is the forecastable side — fastCRW's flat credit model — worked at scale, so you have a concrete baseline to compare your own Apify estimate against.
| Workload (per month) | fastCRW credits | How it is computed |
|---|---|---|
| 10,000 static scrapes | 10,000 | 1 credit/page |
| 10,000 scrapes, all chrome-rendered | 10,000 | 1 credit/page (same as any renderer) |
| 10,000-page crawl | 10,000 | 1 credit/page |
| 10,000 JSON extractions | 10,000 + LLM token cost | 1 credit/request + usage-metered LLM token cost |
The point is not the exact credit totals — it is that every web-fetch cell is computed from a single input you control (page volume) times a published per-operation rate; extraction adds a usage-metered LLM token cost on top of its 1-credit scrape, and there is no proxy or compute variable anywhere in the formula. You can do the page-fetch math on a napkin before you write a line of code.
And there is a hard escape hatch at the top of the curve. Self-hosting the AGPL-3.0 engine costs $0 per 1,000 scrapes — you pay only for your own server. For large recurring jobs, that caps your worst-case cost at a VPS bill rather than an open-ended metered total, which a hosted-only platform structurally cannot offer. For a broader treatment of where the curve bends, see the cost of web scraping at scale.
Where Apify genuinely wins
To be fair about it:
- The Actor marketplace. Thousands of prebuilt, community-maintained scrapers for specific sites. If one already covers your target, you skip the build-and-maintain cost entirely — and that can beat any flat-rate API on total cost of ownership.
- Proxy depth and anti-bot. A managed residential proxy pool and mature anti-bot infrastructure that fastCRW does not match. For aggressively defended targets, that depth is the product.
- Orchestration and scheduling primitives. A general compute platform with storage, schedules, and integrations baked in — more than a stateless scrape/crawl primitive offers out of the box.
- Pay-only-for-what-runs. For spiky, irregular workloads, a pure compute meter can be cheaper than a credit allowance you do not fully use — the same flexibility that makes it hard to forecast also makes it efficient when usage is genuinely variable.
Which cost model fits your workload
The choice comes down to predictability versus breadth. If your spend forecast has to be defensible to a finance team, if your volume is steady, and if you can express your job as scrape/crawl/map/search/extract, a single-dimension credit model is the more forecastable shape — and self-host gives it a hard floor. If your value is concentrated in long-tail Actors, deep proxy infrastructure, or genuinely spiky compute, Apify's stacked model earns its complexity. Map your real workload onto the per-1,000-page math above, compare it against your own Apify estimate built from CU, proxy, and per-result lines, and let the two numbers decide.
Sources
- fastCRW canonical facts
- fastCRW repo and pricing: github.com/us/crw · fastcrw.com
- Apify pricing (verify live, characterized qualitatively here): apify.com/pricing
Related: Apify pricing explained · Apify vs fastCRW · Cost of web scraping at scale