Apify cost optimization
Quick answer: how to reduce Apify costs
Start by capping the number of billable events, not by tuning memory. On most paid Store Actors you are billed per event, and the developer covers the compute, so memory settings do not touch your invoice at all. Set a maximum cost per run, switch off the add-on events you do not use, and only then look at compute.
The size of that first lever, with real prices: the Google Maps Scraper charges $0.003/place subject to change · verified 2026-09-10 on the Starter plan, so 10,000 places costs $30. Switch on the "additional place details" and "company contacts" add-ons at $0.002/event subject to change · verified 2026-09-10 each and the same 10,000 places costs $70. No amount of memory tuning recovers that $40.
Compute optimization still matters, but only on the runs where compute is your bill. That is the first thing to check.
Step zero: find out which layer is billing you
Apify Store Actors sit in one of three models, and they bill you very differently. If the moving parts are new to you, the what is Apify overview covers how Actors, Store, proxy, and storage fit together first.
- Pay per event. You pay the developer's per-event prices. Most of these Actors include platform usage in that price, so your CUs are the developer's problem, not yours. Some switch on a "pay per event + usage" option and bill compute separately; the Actor's Pricing tab says which. You still pay for reading and storing results, typically cents.
- Pay per usage. No developer fee. You pay platform usage only: compute units, proxy, data transfer, storage operations. This is where every compute tactic below actually pays off, and it is also how your own Actors bill.
- Rental. A flat monthly fee plus platform usage. Apify is retiring this model: since 1 April 2026 no new rental Actors can be published, and on 1 October 2026 all remaining rental Actors are migrated to pay-per-usage pricing. Do not build a cost model around rental in September 2026.
Compute units are the platform's meter: memory in MB multiplied by hours, where 1024 MB for one hour is 1 CU. The price per CU depends on your plan.
| Plan | Monthly price | Credits included | CU price | CUs the credit buys |
|---|---|---|---|---|
| Free | $0 | $5 | $0.20 | 25 |
| Starter | $19/mo subject to change · verified 2026-09-10 | $19 | $0.20 | 95 |
| Scale | $199 | $199 | $0.16 | 1,243 |
| Business | $999 | $999 | $0.13 | 7,684 |
Note the pattern: the included credit is exactly the plan fee divided by the plan's CU price. That makes each plan behave like a per-CU rate with a minimum spend, which is what makes the upgrade math in section 10 simple.
Tactics ranked by how much they save
| Tactic | What it saves | Effort | When it applies |
|---|---|---|---|
| 1. Cap max cost per run and account limits | A hard ceiling you choose; the platform enforces it | Low | Every pay-per-event Actor |
| 2. Switch off add-on events | 57% in the Google Maps example ($70 to $30 per 10,000 places on Starter) | Low | PPE Actors with optional events |
| 3. Avoid residential proxy where datacenter works | $8/GB, so $40 on a 5 GB run | Medium | Sites that do not demand residential IPs |
| 4. Cut schedule frequency | Hourly to daily is 24x fewer runs, a straight multiplier | Low | Monitoring jobs |
| 5. HTTP crawler instead of a browser | Browsers have a 1024 MB floor; HTTP crawlers do not | Medium | Data already in HTML or XHR JSON |
| 6. Right-size memory | Proportional, but only on single-task runs | Low | Single-URL or short isolated jobs |
| 7. Batch inputs | One start event instead of N; cents on PPE, more on pay-per-usage | Low | Actors charging an actor-start event |
| 8. Trim fields and block assets | Little on dataset writes, real on proxy gigabytes | Medium | Media-heavy pages |
| 9. Move enrichment downstream | Shifts LLM and API cost off the metered run | Medium | Heavy in-run enrichment |
| 10. Move up a plan above the crossover | $0.20 to $0.16 per CU above 995 CU/month | Low | Sustained compute-heavy usage |
1) Cap the spend before the run starts
The strongest control is the per-run maximum cost, which the platform enforces rather than merely suggests. Once a pay-per-event run hits the limit you set, Actor.charge() stops charging, pushData() stops writing past the cap, and the platform aborts the run. Developers can set a floor on how low you may set that cap, stored as minimalMaxTotalChargeUsd, so a very small ceiling may be rejected.
- Example: monitoring 500 SKUs on an Actor that charges $0.004 per result should carry both
maxItems: 500and a max cost per run near $2.20, so a bad input selector cannot turn into a category-wide crawl. - Account level: the Limits tab in Console suspends platform services when you pass your plan's limits, or bills the excess as overage if you enable it. Overage is invoiced immediately once it reaches $20 on Starter or $200 on higher plans. See Billing.
Set both. The run cap protects you from one bad run; the account limit protects you from a bad week.
2) Switch off add-on events you do not use
Pay-per-event Actors increasingly stack optional events on top of the base result, and they are usually toggled by an input field you may have left on by accident. On the Google Maps Scraper the base place-scraped event is $0.004/place subject to change · verified 2026-09-10 on the Free plan and $0.003 on Starter, while place details, company contacts, and filter applied each add their own charge on the same row.
Read the Actor's Pricing tab as a menu, not a single price. Then run 20 inputs, open the run's charges breakdown, and confirm you are only paying for events you actually consume downstream.
3) Keep residential proxy off unless the site forces it
This is the cost line most people miss, because it is invisible until the invoice. Residential proxy is billed by the gigabyte at $8/GB subject to change · verified 2026-09-10 on Free and Starter, $7.50 on Scale, and $7 on Business. Datacenter proxy is included with your plan instead: 5 IPs on Free, 30 on Starter, then $1 per extra IP.
- Example: a run that pulls 5 GB through residential IPs costs $40 in proxy alone, more than double a Starter plan's entire $19 monthly credit.
- Escalate, do not default. Start on datacenter, measure the block rate, and move only the targets that genuinely fail. Splitting one job into a datacenter tier and a small residential tier is usually cheaper than putting the whole crawl on residential.
- Blocking images, fonts, and media in a browser run cuts residential gigabytes directly, which is the expensive meter here.
4) Match the schedule to the decision cadence
Hourly runs are 24x the billable surface of daily runs, on every meter at once: compute, proxy, and events. If the pricing decision happens weekly, scraping hourly buys nothing but a larger invoice.
- Example: MAP monitoring may justify daily. Full category exploration rarely justifies more than monthly, with history kept in a dataset or warehouse.
5) Use an HTTP crawler where the data is already in the HTML
Playwright and Puppeteer launch real browsers, and Apify's own docs set a hard floor of 1024 MB of memory for any Actor that renders with them. An HTTP-only crawler such as Cheerio has no such floor and can be dropped to 512 MB or lower. That halves the CU rate per hour before you count the extra wall-clock time a browser spends rendering.
- Rule of thumb: if "view source" already contains the fields you need, do not open a browser.
- Example: a directory site that returns listing cards as server-rendered HTML should be parsed with Cheerio, escalating to a browser only for the panels that are genuinely client-rendered.
Official guidance is in the Apify docs on Actor performance.
6) Set memory to the shape of the run, not to a habit
Here is the trap that makes most memory advice wrong. Actors built with Crawlee autoscale, and Apify's docs state it plainly: if you double the allocated memory, the run should be twice as fast and consume the same compute units (1 × 1 = 0.5 × 2). Halving memory on an autoscaled multi-URL crawl usually just doubles the runtime for the same bill.
Memory tuning pays off in two specific cases:
- Single-task runs. Autoscaling only applies to jobs that run multiple URLs for at least 30 seconds. A one-URL job, or a utility Actor doing a single isolated task, runs for a fixed duration, so cutting 4096 MB to 1024 MB genuinely cuts the CUs by four.
- Actors that were simply over-allocated. Apify calls 4096 MB a reasonable middle ground. If yours never approaches it, step down in halvings and watch for OOM kills.
See compute units for the full model.
7) Batch inputs so you pay the start overhead once
Each run carries fixed overhead: container start, login flows, cache warming. Several Actors also bill a synthetic actor-start event, commonly $0.001. Forty small runs pay that forty times.
- Example: instead of 40 runs of 25 ASINs, run one job of 1,000 ASINs with
maxItemsand concurrency set from the Actor README.
Be honest about the size of this one on pay-per-event Actors: 39 extra start events is four cents. The real saving is on pay-per-usage Actors, where cold-start seconds are billed as compute on every single run.
8) Trim payload weight for the proxy bytes, not the dataset rows
Storage operations are cheap enough to ignore in most budgets. Dataset writes cost $0.005 per 1,000 on Free and Starter, so a million rows is $5. Trimming fields will not meaningfully cut that line.
Trim anyway, for the meters that do cost money: external data transfer at $0.20/GB, proxy gigabytes at $8/GB on residential, and runtime spent serializing payloads you never read.
- Drop fields nothing downstream loads.
- Block images, fonts, and media in browser runs unless screenshots are the product.
- Normalize large repeated blobs into a key-value store rather than duplicating them on every row.
9) Move enrichment out of the Actor
Keep the scraper lean: fetch, parse, emit. Run email finding, firmographics, and LLM summarization in downstream jobs where you can scale them separately and skip them on failed rows. Inside the run, a slow third-party API call is billed as compute for its entire wait.
This also protects you from paying twice: if the scrape fails at row 800 of 1,000, you do not want to have already paid for 800 LLM calls inside the same run.
10) Pick the plan from your monthly CU volume
Because each plan's credit equals its fee divided by its CU price, the arithmetic collapses to a rate with a minimum:
- Starter behaves as $0.20 per CU with a $19/month minimum.
- Scale behaves as $0.16 per CU with a $199/month minimum.
- Business behaves as $0.13 per CU with a $999/month minimum.
So the crossovers, assuming compute is the bulk of your bill and overage is switched on:
- Free to Starter: once you pass 25 CU a month, which is 25 hours of a 1024 MB Actor. The Free plan stops at $5 of credit, so the real cost of staying is paused work.
- Starter to Scale: at about 995 CU a month ($199 ÷ $0.20). Below that, Scale's per-CU discount cannot repay the $180 difference in fee.
- Scale to Business: at about 6,244 CU a month ($999 ÷ $0.16).
Current list prices are on Apify pricing. For how per-event rates stack on top, see pay-per-event pricing and Apify's pricing and costs reference.
Operating playbook (what actually prevents waste)
- Sample run on 10 to 50 inputs.
- Open the run details and read both the charges breakdown and the platform usage. Note which one is larger. That decides whether you optimize events or compute.
- Apply the cap first, then the tactic that matches your billing layer.
- Extrapolate:
monthly cost ≈ (runs/month × billable events/run × event price) + (runs/month × CU/run × CU price) + proxy GB × GB price. - Only then promote to a production schedule.
Monitoring
In Apify Console → Billing, the Historical usage tab breaks down compute units and cost per Actor, and the Current period tab splits usage across Actors, data transfer, proxy, and storage. Optimize cost per good row, not raw monthly spend. A cheaper Actor with a worse success rate can cost more once retries are counted, and failed runs still burn compute and proxy bytes.
Run a small pilot, read the charges breakdown, then scale with a max cost per run in place.
Every price on this page was verified against Apify's pricing page and platform documentation on 10 September 2026. Verify before financial planning.
Set a maximum cost per run, then check which layer is billing you. On a pay-per-event Actor your bill is events multiplied by their price, and the developer usually covers compute, so switching off add-on events beats any memory tuning. On a pay-per-usage Actor the compute tactics apply instead.
No, and this is the most common mistake. Crawlee-based Actors autoscale, so Apify's docs state that doubling memory makes the run roughly twice as fast for the same compute units. Halving memory on a multi-URL crawl often just doubles the runtime. Memory cuts help on single-task runs, on jobs shorter than 30 seconds, and on Actors that were simply over-allocated.
8 dollars per GB on the Free and Starter plans, 7.50 on Scale, and 7 on Business, verified on 10 September 2026. Datacenter proxy is included instead: 5 IPs on Free and 30 on Starter, then 1 dollar per extra IP. A 5 GB residential run costs 40 dollars in proxy alone, which is why escalating from datacenter rather than defaulting to residential is usually the largest single saving after event caps.
Cheerio, when the page does not need a browser. Apify's docs require at least 1024 MB of memory for any Actor rendering with Puppeteer or Playwright, while an HTTP crawler has no such floor and can run at 512 MB or less. Playwright is still justified for client-rendered SPAs, JavaScript challenges, or genuine DOM interaction.
maxItems stops the run after a set number of results. The max cost per run is stronger because the platform enforces it: once the cap is hit, charging stops, pushData stops writing past it, and the run is aborted. Developers can set a minimum for that cap, so a very low ceiling may be rejected.
Free includes 5 dollars of credit, which is 25 compute units at 0.20 per CU, so move to Starter once you consistently exceed 25 CU a month. Starter effectively costs 0.20 per CU with a 19 dollar minimum and Scale costs 0.16 with a 199 dollar minimum, so Scale only wins above roughly 995 CU a month.
Usually not. Most pay-per-event Actors include platform usage in the event price, and the developer absorbs the compute. Some developers switch on a pay-per-event-plus-usage option that bills compute separately, and the Actor's Pricing tab says so. You always pay for reading and storing results afterwards, which is typically cents.
No. Apify is retiring the rental model. New rental Actors could no longer be published from 1 April 2026, and on 1 October 2026 all remaining rental Actors are migrated to pay-per-usage pricing. Plan around pay-per-event and pay-per-usage instead.
In Apify Console under Billing. The Historical usage tab shows compute units and cost broken down per Actor, and the Current period tab splits usage across Actors, data transfer, proxy, and storage.