Apify Actor Passive Income: What Actually Earns in 2026 (And What the Guides Get Wrong)

Almost every guide ranking for "Apify passive income" right now tells you to publish a scraper, put a $30/month subscription on it, and collect rent. That advice is describing a pricing model Apify is in the middle of switching off. New rental listings stopped on April 1, 2026, and the model retires completely on October 1, 2026, at which point remaining rental actors get migrated to pay-per-usage.

So if you follow the top-ranked advice this week, you build for a business model that will not exist by the time your actor has users.

I taught a live session on this in May — building production-ready actors with an agent, plus the repo framework and the launch playbook — and the pricing ground has shifted under it since. This post is the current version: what actually earns on the Apify Store in 2026, the arithmetic nobody publishes, how I use Claude Code for the build, and the parts of "passive" that are not passive at all.

I'll say up front what I am not going to do: I am not going to quote you my own actor revenue as proof. I run about 14 launched products and three content properties, and my actors are a small line item next to those. What I can give you is verified platform numbers, the pricing mechanics in detail, and an honest read on the build workflow, because that is the part I actually run every day.

Can you really make passive income with Apify actors?

Yes, and the honest range is much wider than the case studies suggest. Here are the numbers straight from Apify rather than from a guide quoting a guide:

• Apify's own help documentation states that "the most successful independent creators on Apify Store make over $10,000 monthly recurring revenue" and that many others make more than $1,000 every month. That is from Apify's page on making money publishing actors.

• Apify's actor developer partner page states it pays out $1.4M monthly to developers, across roughly 3,000 community developers.

• The same page lists 53,954 tools and automations currently in the store, with 10,000+ new signups daily.

Now do the division that no ranking article does. $1.4M spread across 3,000 developers averages roughly $470 per developer per month. That average is heavily skewed — a handful of top actors pull five figures, and plenty of published actors earn nothing — but it is the most honest single number in this whole category. It tells you the realistic first outcome is a few hundred dollars a month from a small portfolio, not a replacement income from one clever scraper.

Notice how far off the older guides are. One widely shared passive income article, published by Apify itself and syndicated to developer communities, cites a top earner at $4,000+ monthly and describes a store with 1,500+ tools. Apify's current pages say $10,000+ and 53,954. The opportunity got bigger and the shelf got roughly 35 times more crowded, and the articles ranking for the keyword describe neither.

The 2026 Apify pricing change every passive income guide missed

This is the part that changes what you should build, so it goes before any tutorial steps.

Rentals are being retired, and pay-per-event replaces them

Apify has publicly explained the standardization: the flat monthly fee is going away in favor of pay-per-event. Apify's stated reason is customer preference — in their survey, 73% of customers said they preferred pay-per-event over fixed rentals. They had already migrated about 2,000 actors from pay-per-result to the more granular pay-per-event system before turning to the rental ones.

The models that matter now, per Apify's documentation:

• Pay per event. You define the billable events in your own code and charge for them. This is the flagship model and where new actors should start.

• Pay per usage. The user pays platform usage costs, with no developer margin on top. This is where unmigrated rental actors land by default.

• Pay per result. Charging per dataset item. Still around, but Apify has been actively moving actors off it onto pay-per-event.

Commission is straightforward and worth memorizing: Apify keeps 20%. On pay-per-result and pay-per-event, Apify deducts the platform costs used to run the actor plus a 20% commission from your profits. Apify's marketing playbook phrases the same thing from your side as earning 80% of revenue minus platform usage costs. Payouts run monthly.

There is a second reason for the change, and it is the important one

Buried in the pricing announcement is the fact that reframes this whole category: Apify's MCP server excludes rental actors from search results. An actor on the retired model is invisible to AI agents that discover and call tools dynamically.

Read that again with your builder hat on. The store is being rebuilt so that the customer running your actor is increasingly a language model in the middle of a task, not a person browsing a marketplace. Pay-per-event exists because an agent pays per action it takes. That is why the flat monthly rental had to die — an agent does not want a subscription, it wants to call one function, once, and pay for that call.

What the pricing model change means for what you should build

Once you accept that a meaningful share of your future users are agents, three build decisions change.

Design one clear action, not a dashboard. An agent picks a tool from a short description and an input schema. Narrow, obviously-named actors that do one thing get selected. Broad "do anything on this site" actors with fifteen optional parameters do not, because the model cannot tell whether the tool fits and gambles elsewhere.

Make your input schema the documentation. Your schema is what the agent reads to decide if it can call you. Vague field names and missing descriptions are now a discoverability problem, not just a UX one. Apify's own guidance on store ranking is that search ranking evaluates parameters similar to the actor quality score and the two correlate strongly, and that the same score influences ranking in the MCP server tool.

Instrument the events you would actually want to bill for, early. Retrofitting billable events into a scraper you wrote as one monolithic run is annoying. Deciding up front that "one enriched profile" or "one page rendered" is the unit makes pricing a one-line change later.

Picking a niche against 53,954 existing tools

The saturation number is the one you should sit with. With nearly 54,000 tools published, "build an Instagram scraper" is not a plan — there are established actors with thousands of monthly users, star ratings, and success-rate metrics that a new listing cannot match on day one.

What I look for instead:

1. A source that changes shape often enough to scare people off. Breakage is the moat. If a target site ships layout changes quarterly, the abandoned-actor graveyard is deep and a maintained actor wins on the success-rate metric alone.

2. An output an agent would want mid-task. Not "scrape all of X" but "given one identifier, return the five fields a workflow needs." Small, callable, cheap.

3. A niche I already have a reason to be in. I build tools that touch things I actually operate, because then I am my own first user and I notice breakage before a customer files a ticket.

4. Something I can price above its platform cost with room to spare. Apify's playbook notes most prices on the store range between $1 and $10 per 1,000 results. If your actor burns heavy compute per result, that ceiling is a real constraint, not a detail.

How I build an Apify actor with Claude Code (and what I refuse to delegate)

The build half is where an agent earns its keep, and it is also where people oversell it. Here is the split I actually use.

The agent does the scaffolding and the plumbing well. Generating the actor skeleton, writing the crawler logic against a page structure I paste in, filling out the input schema, drafting the README, wiring the charging calls, and iterating against real runs until the output shape is right. This is the same "boring 80%" pattern I lean on across all my products, and it is the honest reason a session-length build is possible at all. If you want the general version of this, I wrote about running a team of AI subagents across my products and about why I stopped buying prompt packs and started building systems — an actor is just another system with a state boundary and a paid trigger.

Four things I do not hand off:

The billing calls. In the Apify SDK you charge by calling the actor's charge method with an event name, and the call returns a result object you are supposed to inspect. Two details matter and agents skip both unless told: users can cap spend per run, and when that cap is hit, charging stops, data pushing stops, and the run gets aborted. Your code should check the returned charge-limit-reached flag and exit gracefully with a clear message instead of dying mid-write. Apify documents the pay-per-event mechanics properly, including the automatic synthetic events like actor start.

The charge-on-partial-failure policy. Apify's guidance is to charge for work already performed even when it errors — a URL that returns a 404 still consumed resources — and to return an error item with a clear message rather than failing the whole run. That is a judgment call about your customer relationship. I write those rules by hand and put them in the project instructions so every later change respects them.

The README's first three lines. That is the sales page and the agent-facing tool description at once. I let the model draft it, then I rewrite the top.

Whether the thing is honest. If an actor's output quality degrades because a target site changed, it needs to say so loudly rather than silently return thin results a customer pays for.

Practically, my loop is plan mode first, then let it build against a real run, then review. Anthropic's common workflows documentation covers the mechanics — plan before editing, delegating exploration to subagents, resuming a session across sittings — and all three matter on a build like this, because a scraper is mostly a long argument with one stubborn page.

Pricing an actor without guessing

Three steps, in this order:

1. Measure your platform cost per unit first. Run the actor on a realistic batch and read the actual usage. You cannot price a margin you have not measured, and pay-per-event bills events while your costs are compute and proxy traffic.

2. Price the event, not the run. Pick the unit the customer thinks in — one profile, one listing, one rendered page — and charge that. Then a heavy run and a light run both make sense to the buyer.

3. Resist passing platform costs through permanently. Apify lets you temporarily enable pay-per-event plus usage during development, but explicitly warns it reduces pricing transparency and can hurt your quality score. Use it while you calibrate, then fold the cost into your event price.

One more thing worth knowing before you set a number: pricing changes come with a notice period rather than taking effect instantly, so treat your launch price as something you live with for a while rather than a dial you spin weekly.

What "passive" actually costs

The honest version, from running maintained software rather than from a case study:

• Scrapers break, and they break on the target's schedule, not yours. The older guides estimate 5-10 hours of maintenance every three months. That is plausible as an average across a stable portfolio and wildly optimistic for a single actor pointed at a site that is actively fighting scrapers.

• Your success-rate metric is public. Users see monthly user counts, star ratings, success rates, and response times before they try your actor. A quiet week of failures is visible to every future buyer, which means neglect compounds.

• Support is real, even if light. People will ask for fields you did not build.

• You are exposed to platform terms. Commission, model availability, and store mechanics are Apify's to change — as the rental retirement just demonstrated. Building a portfolio of several small actors rather than one big earner is the only hedge I trust.

None of that makes the model bad. It makes it a maintained asset instead of a lottery ticket, which is a much better thing to own anyway. The monitoring side of this is the same discipline I use for my content properties, where a scheduled check runs whether or not I am at the desk. If that pattern is new to you, my post on the marketing automation system I run every morning shows the shape of it.

Watch the full build session

The live training this post grew out of is Code to Cash: Passive Income with Agent Built Apify Actors, and the full replay is available instantly — you can get the session and watch it right now rather than waiting for a date. It covers the parts a blog post cannot: the actual 30-minute build on screen, the reusable repo framework, the prompts, and the marketing playbook for getting a listing found.

If you read this far and the pricing section was the useful part, the replay is where the build becomes muscle memory.

Go deeper with the Accelerator

The Reinventing AI Accelerator is where the live training sessions happen, plus the vault of AI apps, tools, and agents that come out of them. Members get the sessions as they run and the full back catalog of builds — including the actor framework from this one. If you are building things you intend to sell rather than collecting tutorials, that is who it is for. One small ask: watch one replay end to end and ship the thing before you decide whether it was worth it.

Frequently asked questions

How much can you actually earn from one Apify actor?

Apify's own documentation says top independent creators exceed $10,000 monthly recurring revenue and many developers clear $1,000 a month. But the platform-wide arithmetic — $1.4M paid monthly across roughly 3,000 developers — puts the average nearer $470 a month, and that average includes a long tail earning nothing. Plan for a portfolio of small earners, and treat a single four-figure actor as an outcome you earned, not a baseline.

Is the Apify rental pricing model really going away?

Yes. New rental listings stopped April 1, 2026, and the model fully retires October 1, 2026, with remaining rental actors migrated to pay-per-usage. Apify's stated reasoning is that 73% of surveyed customers preferred pay-per-event, and that rental actors are excluded from its MCP server's search results — so they are invisible to AI agents selecting tools. If a guide tells you to set a flat monthly fee, it is out of date.

Do you need to know how to code to publish an actor?

You need to be able to read code and judge output, which is not the same as writing it from scratch. An agent can generate a working crawler, an input schema, and the charging calls. What it cannot do for you is decide whether the data is correct, whether the billing behaves fairly when a run hits a spend cap, or whether the target site's structure will hold. Publishing something you cannot debug is how you end up with a public success-rate metric you are ashamed of.

What is the difference between pay per event and pay per result?

Pay per result charges per dataset item produced. Pay per event lets you define the billable actions yourself in code and charge for each one, so you can bill for things that are not rows — a page rendered, an external API call, a run started. Pay per event is the model Apify is standardizing on, and it is the better fit when your cost per output varies or when the value you deliver is an action rather than a row.

How long does it take to get from an idea to a published actor?

The build is the short part — a focused actor with an agent doing the scaffolding is genuinely a session's work. Getting it to earn is the long part: measuring platform cost per unit, setting a price you can live with, writing a listing that a human and a tool-selecting model both understand, and then maintaining it through the first few times the target site changes. Budget an afternoon for version one and a few months before you judge the revenue.