> ## Documentation Index
> Fetch the complete documentation index at: https://docs.talosjs.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Caching

> How the per-seed run cache skips seeds whose code is unchanged.

`seed:run` keeps a per-seed run cache so a seed whose code is unchanged since its last successful run — for the same environment — is skipped without touching the database. Unlike [migrations](/migrations/caching), seeds have no database table recording what has run, so this cache is the only record that a seed already ran. When every selected seed is already cached, the runner reports each as `up to date (cached)` and returns without re-seeding.

## What the cache stores

One JSON file per seed lives under `var/cache/seeds/` at the project root, so editing a single seed invalidates only that seed's entry. Each entry records the cache version, the seed name, a fingerprint hash, and the time it ran. Only successful runs are written, and the directory is safe to delete at any time.

## How an entry is fingerprinted

The hash covers the seed's class name, the source of its `run` method, and the active environment (`APP_ENV`). Any change to the seed's code — or running against a different environment — yields a new hash and therefore a cache miss, so the seed runs again.

## When the cache is bypassed

| Trigger      | Effect                                                                                                                       |
| ------------ | ---------------------------------------------------------------------------------------------------------------------------- |
| `--drop`     | Seeded data is cleared, so a cache hit would wrongly skip re-seeding; the cache is bypassed and every selected seed re-runs. |
| `--no-cache` | Explicit escape hatch — reads and writes are skipped for the run.                                                            |

Like any cache decoupled from live database state, an entry can go stale if the database is reset out of band — `--drop` and `--no-cache` exist for exactly that case.

## Next steps

* [Running seeds](/seeds/running): run seeds, with or without the cache.
* [Overview](/seeds/overview): why seeds rely on the cache instead of a tracking table.