Nx hashes a task's inputs, such as project files, configuration, external dependency versions, runtime values and command line arguments, then stores the terminal output and the configured output files under that hash. It does not store the source inputs themselves, only their hashes.
The hash
Before running a cacheable task, Nx calculates a hash. Two runs with the same hash represent the same computation, so the earlier result can be reused. According to the Nx documentation, a hash can include:
- Project source files and files from project dependencies.
- Relevant workspace configuration.
- Versions of external dependencies.
- Runtime values such as operating system and CPU architecture.
- Command line arguments passed to the task.
Different command forms that create the same task with the same arguments give the same hash. A build with an extra flag gets a different hash.
What a cache entry holds
| Part | Stored? |
|---|---|
| Terminal output from standard output and standard error | Yes |
| Files and directories matched by the target's outputs setting | Yes |
| The task hash that identifies the entry | Yes |
| Source files and other inputs | No, only their hashes feed the key |
Lookups go local first, then the remote cache if configured. On a hit, Nx restores the files and prints the stored terminal output. On a miss it runs the task and stores the result locally, and in the remote cache when authentication permits writes.
Why this matters for security
Outputs are copied to other machines. Anything a build writes into an output directory, including generated configuration, can be restored on another developer's laptop or a CI runner. Audit what your build writes into outputs, especially files that embed environment values.
Terminal output is stored too. A log line that prints a token is saved and replayed. Keep secrets out of task output.
Inputs decide correctness. Nx includes all files under a project root by default, and lets you narrow inputs, or add environment variables and runtime values. The docs advise starting safe: include more than strictly necessary, and fine tune only when there is a clear opportunity. If an environment variable changes build output but is not an input, a cache hit can restore output built under a different value.
External dependency versions are inputs. Because versions of external dependencies feed the hash, a lockfile change that changes a version produces a new hash for affected tasks. That is useful: dependency updates cannot silently reuse stale outputs.
A checklist
- List output directories for each cacheable target. Make sure outputs are explicit rather than guessed.
- Review inputs for tasks that read environment variables, and add those variables as inputs.
- Check task logs for secrets. Rotate anything found.
- Treat a remote cache as shared state and limit who can write.
- Test by changing one declared input at a time and confirming a miss.
Where Safeguard fits
Safeguard can inventory the dependencies your repository declares through SBOM and dependency scanning, and reachability analysis helps you decide which findings matter first. You can try a free scan on a repository to see what it finds. Check coverage for your specific build files before relying on it.
Try it yourself
Open the demo and look at how a dependency version appears in an inventory. In Nx that version also feeds the task hash, so a change in one place should show up in the other.
Click through it at your own pace, or open it full screen.
Quick check
Does the Nx cache store my source files?
No. The entry holds terminal output, output files and the hash. Source files contribute only through their hashes.
If I forget an input, what happens?
Nx can reuse an output built from different data, because the hash did not change. Include more inputs than strictly necessary when unsure.
Sources
Last reviewed: 19 October 2026.
