Apify cost optimization
Quick Answer
Reduce Apify costs by: using Cheerio over Playwright where possible, reducing Actor memory, batching inputs efficiently, setting maxItems limits, and switching to Starter plan when usage exceeds Free tier.
Apify bills platform usage (compute units, proxy traffic, storage time) and, for many Store Actors, a second layer such as pay-per-result, pay-per-event, or rental fees. Optimization is therefore two-dimensional: shrink CPU-seconds and Actor charges together.
The two cost layers (always check both)
- Platform usage (CUs, etc.): driven by memory × runtime, retries, browser launches, and heavy post-processing inside the run.
- Actor / Store pricing: may charge per item, event, monthly rental, or hybrid. Open the Actor Pricing tab before you scale.
If you optimize CUs but ignore per-result fees (or the reverse), you can still overspend.
Strategy table: impact vs complexity
| Strategy | Typical impact | Complexity | Best for |
|---|---|---|---|
| Cheerio / HTTP first; Playwright only if needed | High | Medium | Static HTML or JSON-in-page sites |
| Lower Actor memory | Medium–high | Low | Any long-running or bursty workload |
| Batch inputs (fewer runs, fuller datasets) | Medium | Low | Pay-per-run friction or cold-start overhead |
| maxItems / max results / run budget caps | High | Low | Pay-per-result Actors and production guardrails |
| Right-size schedules | Medium | Low | Monitoring jobs that do not need hourly freshness |
| Strip unused fields & assets | Medium | Medium | Wide schemas and media-heavy pages |
| Move enrichment out of the Actor | Medium | Medium | Heavy joins, ML, or formatting in-run |
| Upgrade Free → Starter when credits burn monthly | High (predictability) | Low | Teams consistently exceeding free credits |
| Pick pricing model to workload shape | High | Medium | Steady volume vs bursty spikes |
1) Prefer Cheerio (HTTP) over Playwright when possible
Playwright and Puppeteer spin up browsers, which is expensive in CUs and wall time. Cheerio (or plain fetch + parsing) is much cheaper when the data is already in HTML or XHR JSON.
- Example: A directory site returns listing cards as HTML. Parse with Cheerio, follow pagination URLs, and only escalate to a browser if a panel is truly client-rendered.
- Rule of thumb: If “view source” already contains the fields you need, do not open a browser.
Official performance guidance lives in Apify docs on Actor performance.
2) Reduce Actor memory
Compute units scale with allocated memory. Many Actors default to a safe but high value.
- Example: If RSS or JSON extraction uses under 300 MB RAM, dropping from 4096 MB → 1024 MB cuts CU proportionally for the same duration.
- Guardrail: Too little memory causes OOM kills, so step down in 512 MB increments after profiling.
See compute units for the mental model.
3) Batch inputs efficiently
Each run has fixed overhead (startup, login flows, cache warming). When targets allow, prefer one larger, well-bounded run over dozens of tiny ones, especially if you pay per run or per minimum chunk.
- Example: Instead of 40 runs × 25 ASINs, run 1 × 1,000 ASINs with
maxItemsand concurrency tuned to the Actor README.
4) Set maxItems, event caps, and billing limits
For pay-per-result Actors, maxItems (or the Actor’s equivalent) is your spend circuit breaker.
- Example: Product monitoring for 500 SKUs should set
maxItems: 500(plus a small buffer) instead of an open-ended category crawl. - Account level: Use Apify Billing → limits so a typo in input does not drain the wallet. See Billing.
5) Tune schedules to real decision cadence
Hourly runs are 24× the platform surface area of daily runs. If pricing decisions happen weekly, scrape weekly and store history in a dataset or warehouse.
- Example: MAP monitoring might be daily; total category exploration might be monthly.
6) Limit output weight
Bytes written and dataset rows cost money indirectly through longer runtimes and downstream processing.
- Drop fields you never load into BI tools.
- Block images/fonts when using browsers unless screenshots are the product.
- Avoid duplicating the same large blob on every row. Normalize large assets to a key-value store if you control the Actor.
7) Separate extraction from heavy post-processing
Keep the scraper lean: fetch, parse, emit. Run enrichment (email finding, firmographics, LLM summarization) in downstream jobs where you can scale them independently, or skip them on failed rows.
8) Plan upgrade: Free vs Starter
The Free plan includes $5/month in credits, ideal for pilot runs. If you burn credits early every month and pause work, Starter (check current pricing on Apify pricing) often restores throughput and support. That means less firefighting than staying on a capped free tier and forcing oversized single runs.
9) Choose the right Actor pricing model
- Pay per result/event: predictable when you know items per run; pair with
maxItems. - Rental: can win when you run very frequently on the same Actor; recompute rental + CUs vs pure usage.
- Bring your own proxies: sometimes cheaper, sometimes shifts cost to Apify Proxy vs external vendors. Compare total $ per successful record.
Re-read pricing and costs when an Actor updates models.
Operating playbook (what actually prevents waste)
- Sample run on 10–50 inputs.
- Read log + dataset quality and note CU seconds in run details.
- Apply memory,
maxItems, and schedule changes. - Extrapolate:
monthly cost ≈ (runs/month × avg CU/run × CU price) + Actor fees. - Only then promote to production schedule.
Monitoring
In Apify Console → Billing, review usage by Actor, failed runs (retries burn CUs), and dataset growth. Optimize cost per good row, not raw monthly spend. Sometimes a “cheaper” Actor with worse success rates costs more in retries.
Run a small pilot, measure CUs per usable item, then scale with caps.
Guidance in this playbook was cross-checked with Apify pricing and documentation in March 2026; verify before financial planning.
Run a tiny sample, read actual CU usage on the run, then apply memory tuning, maxItems caps, and simpler extraction (Cheerio vs browser). Scaling before measuring is the most common cause of overspend.
Cheerio is far cheaper when pages do not need a full browser. Playwright is justified for client-rendered SPAs, heavy JavaScript challenges, or when you must interact with the DOM like a user.
Many Store Actors charge per extracted item or event. maxItems stops the run after the cap, preventing runaway pagination or accidental category-wide crawls.
When you consistently exhaust free monthly credits before the month ends, need higher limits, or run scheduled production workloads. Compare the list price of Starter to the opportunity cost of throttled runs.
Combine Actor-level caps (maxItems, max cost per run where available) with account billing limits. Test new inputs on small samples before full schedules.
CUs bill platform compute (memory × time). Actor pricing is an additional commercial layer set by the developer: per result, per event, rental, etc. Both can apply on the same run.
In Apify Console under Billing: usage trends, costs by Actor, and historical consumption help you find the top spenders.
It reduces CU if the run still succeeds. Too little memory causes restarts or failures, which can increase total cost. Drop memory gradually while watching logs.
Sources
