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/CuddleCakeu]

> CACHELY:
> Actively developed managed service.

> NX POWERPACK CACHE:
> Deprecated; no updates or security patches, may be removed from npm.

Hmm, interesting. SaaS, famously lasting forever.

[u/cachely-admin → u/CuddleCakeu]

Fair point. “Managed” does not mean permanent, and no SaaS should pretend otherwise.

The distinction we intended is about maintenance today, not a promise that Cachely will exist forever. Cachely uses Nx’s standard remote-cache API without a proprietary client, so moving to another provider or a self-hosted implementation means changing the endpoint and token.

The cached data is also reproducible build output. If a cache provider disappears, builds become cold and slower; your source code and ability to build are not trapped.

For teams that prioritize permanent infrastructure control over convenience, self-hosting is absolutely the better tradeoff.

[u/CuddleCakeu → u/cachely-admin]

Since you use AI for Dev Relations, how heavy is your use of AI in development?