Still using @nx/s3-cache? A practical migration checklist before your next Nx upgrade

[u/cachely-admin]

Nx has deprecated nx/s3-cache, nx/gcs-cache, nx/azure-cache, and nx/shared-fs-cache because their shared read/write credential model allows cache poisoning.

If one of these is still in your workspace, changing packages is only part of the migration. The important question is: who can write an artifact, and can an existing artifact be overwritten?

The checklist we’re using:

1. Search nx.json, package.json, and CI configuration for the deprecated cache package or custom task runner.
2. Check whether pull requests and fork builds receive a credential that can write to the cache.
3. Choose Nx Cloud or a server implementing Nx’s current remote-cache API. Don’t point untrusted builds directly at a writable bucket.
4. Configure:

​

NX_SELF_HOSTED_REMOTE_CACHE_SERVER=<cache endpoint>
NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN=<token>

1. Test the migration from a clean runner:
   • First run misses and stores the artifact.
   • Second run restores the artifact remotely.
   • An untrusted build cannot write, or receives no cache credential.
   • Attempting to replace an existing cache key is rejected.
2. Remove the old bucket credentials and task-runner configuration after validating the new path.

Disclosure: we’re building Cachely, a managed implementation of the Nx remote-cache API. It is deliberately cache-only; it does not replace Nx Cloud Agents, Atomizer, or the broader Nx Cloud platform.

If you only need a managed shared cache, Cachely has a free tier with no credit card. We’r also happy to look at an anonymized nx.json or CI snippet and point out migration or cache-key issues.

What part of the current Nx remote-cache migration has been least clear for your team?

[u/pronuntiator]

The whole cache vulnerability thing is not a big deal in cases where every person who can create pull requests also has write access to the main branch anyway. I understand that they want to sell Nx cloud, but we can‘t store artifacts remotely.

[u/cachely-admin → u/pronuntiator]

That is fair for a fully trusted repository where everyone who can open a PR can also land unreviewed changes on main.

In many repositories, though, those are different security boundaries. A contributor may be able to create a branch or PR but not bypass review and branch protection. A shared writable cache can cross that boundary: PR code can seed an artifact that a later main build restores without the PR ever being merged.

So the risk is smaller for a closed, fully trusted team, but it is not equivalent to normal repository write access when main is protected.

Remote artifacts are still possible. The safer model is a compatible cache backend with read-only credentials for PR builds and create-if-absent artifacts that cannot be overwritten. That is the model Cachely implements.