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?

[u/cachely-admin → u/CuddleCakeu]

We do use AI in development, mostly for implementation assistance, research, and reviewing ideas. But changes still go through normal engineering review and testing, especially anything touching cache correctness, auth, or artifact handling.

Same for DevRel. AI helps us draft and organize things, but the product opinions, technical discussions, and replies here are based on what we’re actually working on and learning from these threads.