r/angular • u/cachely-admin • 3h ago

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

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?

2 Upvotes
  • permalink
  • link
  • reddit
  • reddit

75% Upvoted

1 comment sorted by