Apify Remembers the Run. It Does Not Remember Between Runs.

You put an Apify Actor on a schedule: every morning at 6, it scrapes a competitor's pricing page and pushes the results to a dataset. Monday it reports 48 products. Tuesday it reports 48 products. Wednesday, the same. Nothing changed, yet your downstream workflow fires 48 "updates" a day, because the Actor has no idea what it saw yesterday. Each run is a stranger to the last one.

That is not a bug. It is the design. An Apify Actor run is an isolated execution: fresh environment, input in, dataset out. When the run ends, its world ends with it. If you want the Actor to remember anything between runs, you have to give it a memory explicitly. Apify does give you one. Most scheduled Actors just never use it.

What each run gets (and what it doesn't)

Every Actor run is automatically linked to a default key-value store, created for that run. The run's input lives there, and the run can stash files and records there while it works. It also gets a default dataset for its structured output.

The key word is "that run." The default store belongs to the run, not to the Actor. Schedule the same Actor for tomorrow and tomorrow's run gets a brand-new default store. Nothing from today follows it. Datasets tell the same story: each run writes to its own dataset, which is why scheduled scrapes produce a neat pile of per-run datasets instead of one evolving record of the world.

So the honest answer to "does Apify remember between runs" is: the run remembers everything about itself, and nothing about any other run.

Named key-value stores: the memory Apify actually gives you

The fix is the named key-value store. Open a store by name instead of relying on the default, and you get storage that persists across runs:

const store = await Actor.openKeyValueStore('price-monitor-state');

store = await Actor.open_key_value_store(name='price-monitor-state')

Same name, same store, every run. The next run opens price-monitor-state and finds exactly what the last run left there. There is no background "memory" feature to enable and no toggle in the console. You read state at the start of the run and write state at the end. That read/write pair is the memory contract, and your Actor's code is what enforces it.

In practice, scheduled Actors use named stores for a small set of patterns:

Snapshots for change detection. Save yesterday's scrape under a key like last-prices. At the start of the run, load it, diff it against today's scrape, and only alert on what actually changed. That is the difference between 48 alerts a day and 2.

Dedup registries. Save the IDs of items you already processed (seen-leads, sent-alerts). Check before you act, write after. Your CRM stops filling with duplicates.

Cursors and counters. Save pagination cursors, API quotas, and run counters. A monthly quota tracker has to survive 30 separate runs, and no single run lives long enough to hold it.

One formatting gotcha: record keys in a key-value store only allow letters, numbers, and !-_.'(). Anything else, like colons from timestamps or slashes from URLs, will crash the write, usually on the last line of an otherwise perfect run. Normalize your keys before you save.

Schedules don't change the deal

Apify's Schedules feature runs your Actor, or a saved Task, on a cron. It is tempting to think of a schedule as one long-lived process that wakes up periodically. It isn't. Every scheduled execution is a fresh run: fresh default store, fresh dataset, blank slate. The schedule gives you repetition, not continuity. Continuity is the named store's job, and it only works if your code actually reads the store at startup instead of assuming it knows what happened last time.

Watch one more thing on busy schedules: if two runs overlap, both open the same named store, and the last write wins. Keep state writes small and idempotent, and design the read-modify-write step so a concurrent run can't silently clobber the other one's update.

Where Apify's memory stops

Here is the boundary worth seeing clearly. A named key-value store is memory for the Actor, inside Apify. It does not follow you anywhere else. The n8n workflow that consumes the dataset, the Claude Code session where you debug the Actor, the Make scenario that routes the alerts, the ChatGPT thread where you plan next week's targets: none of them can read that store. Each platform keeps its own memory, in its own format, behind its own API.

That is the deeper version of the same problem. Your agents forget everything between runs, and every tool you add gets its own separate amnesia. Fixing the Actor's memory with a named store is correct, and you should do it. But the memory still lives in one platform's basement.

One memory across all of it

This is what Vilix AI is built for: one memory that every AI tool reads and writes, instead of a separate memory per platform.

Vilix AI is cloud-hosted, so there is nothing to install and no infrastructure to manage. Every tool connects over MCP and shares the same memory: your Apify Actor's run notes, your n8n workflows, Claude Code, ChatGPT, all reading the same context. It stores full conversation history, not just extracted facts, so the reasoning behind a decision survives alongside the decision itself. The free plan is free forever, the Pro trial runs 7 days with no credit card, and you can export or delete everything anytime. Your data stays portable.

The practical setup: keep the named key-value store for the Actor's working state, the snapshots, cursors, and dedup keys. That is what it is good at. Put the cross-tool memory in Vilix AI: what changed this week and why it mattered, which competitor moves you already investigated, the calls you made about pricing strategy. Then the Actor, the workflow, and the chat assistant all start from the same page instead of three different blank ones.

Your Actor will still wake up blank every run. That is fine. Blank is cheap when the memory it needs is one read away, and shared when every tool you use reads the same page.