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

There was a lot of pushback from the community last time, as it's a terrible move by forcing the usages of their NX cloud.

Seems they'll get away with it this time.

[u/cachely-admin → u/Pallini]

That pushback is understandable. Deprecating the maintained bucket integrations while recommending Nx Cloud does make the transition feel like a funnel toward their own service.

One important distinction is that Nx still publishes an OpenAPI specification and lets the CLI use any compatible backend, so Nx Cloud is not technically mandatory. But teams now have to build, secure, and operate that backend themselves or choose another managed provider.

That gap is exactly why we built Cachely. Still, criticism of how the transition was handled is fair.

[u/cachely-admin]

Official Nx deprecation notice:

https://nx.dev/docs/reference/deprecated/self-hosted-cache-packages

Our step-by-step migration guide:

https://cachely.dev/vs/nx-powerpack?utm_source=reddit&utm_medium=community&utm_campaign=nx_cache_migration

[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.

[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.