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?

Disclosure: We’re the team behind Cachely.

We’ve heard two very different experiences from Nx users.

Some teams consider shared remote caching an obvious win for CI and local development.

Others say local caching is enough, their build volume is too low, or differences between developer and CI environments make sharing less useful.

We’re trying to understand where the tipping point is.

For teams using Nx remote caching today:

• How many developers and CI runs did you have when it became worthwhile?
• Which tasks benefit most: builds, tests, linting, Storybook, or something else?
• Do developers and CI share the same cache?
• Do you measure actual time saved, or mainly look at cache hits?
• What still gets rebuilt often enough to be frustrating?
• What would make you stop paying for the service you currently use?

We’re especially interested in setups where remote caching technically works, but the benefit is smaller than expected.

No Cachely link here. We’re trying to better understand which Nx teams genuinely benefit from managed remote caching.

Disclosure: We’re the team behind Cachely.

We’re trying to better understand how Angular teams using Nx handle remote caching once their workspace and CI usage grow.

A few things we’re curious about:

• Are you using Nx Cloud, a self-hosted cache, or an object storage plugin?
• Do developers and CI share the same cache?
• Is remote caching mainly useful for builds, tests, linting, or all of them?
• Can you tell why a task missed the cache?
• Do you measure actual time saved, or mostly look at whether tasks were cached?

We’re building a managed remote cache for Nx, but we’re especially interested in understanding what teams are unhappy with in their current setup.

For teams already using remote caching, what works well and what is still missing?

We recently got useful feedback that remote cache performance should not be judged mainly by large artifact upload and download speeds.

For builds with a high cache hit rate, Action Cache lookup latency may matter more because Bazel can perform a large number of relatively small lookups, while many intermediate CAS outputs are never downloaded.

We’re putting together a benchmark plan and currently considering:

• Cold and warm Action Cache lookups
• p50, p95, and p99 latency
• Throughput under concurrent actions
• Performance with thousands of small actions
• Large CAS uploads and downloads
• Builds from different geographic regions
• HTTP connection reuse
• Cache hit rate compared with total build time saved
• Performance when only top-level outputs are downloaded

A few questions for people operating Bazel at scale:

What does a representative benchmark build look like?

Which numbers would you need before trusting a remote cache for production workloads?

Is there an AC lookup latency where remote caching starts doing more harm than good?

How important is gRPC support compared with a well-performing HTTP cache?

Disclosure: We’re the team behind Cachely. We currently support Bazel’s HTTP remote cache protocol and are investigating gRPC support. There is no product link here. We’re trying to make sure we benchmark the right things before publishing performance claims.

Disclosure: We’re the team behind Cachely. We do not support Yocto today, but we’re researching whether it would be a useful integration.

We recently spoke with a team using Jenkins and Yocto that had been keeping the sstate cache locally on each build node.

That worked while build volume was low, but they are now moving to a centralized cache because the local setup no longer scales.

Their preferred model was:

• Nightly CI builds can read and write
• Developers can read, but not upload
• The cache is available over HTTP or FTP
• Setup should mostly be a URL and credentials
• Nobody wants to spend much time maintaining it

We’re trying to understand how common this setup is.

For teams using Yocto today:

• Where do you store the shared sstate cache?
• Are you using NFS, object storage, Nexus, or a basic HTTP server?
• Do CI and developer machines use the same cache?
• How do you separate read and write access?
• How do you handle retention and different Yocto or machine versions?
• Is on-prem storage a requirement?
• Is the main pain setup, maintenance, performance, or understanding why something missed?

We’re especially interested in whether an HTTP-compatible managed cache would solve a real problem, or whether shared storage is already simple enough for most teams.

Disclosure: We’re building Cachely.

We have been working on managed remote caching for Nx, Turborepo, Gradle, and Bazel.

One thing we keep running into is that setting up a remote cache is much easier than knowing whether it is actually helping.

A hit rate alone does not tell the whole story. A large artifact could take longer to download than to rebuild. A single nondeterministic input could cause repeated misses. Local builds and CI can also behave very differently.

For teams using remote caching today, what do you actually measure?

• Hits and misses by task?
• Time saved?
• Data transferred?
• Compute cost avoided?
• Differences between local development and CI?

What would you need to see before trusting that the cache is worth maintaining?

We built Cachely around managed remote caching and visibility into its effectiveness. We would appreciate feedback from teams running real CI pipelines.