An Nx Cloud alternative for teams that only need remote caching

Who should stay on Nx Cloud

Cachely is a remote cache and nothing more. Nx Cloud does several things it does not, and if you depend on any of them, switching would cost you more than it saves:

• You use Nx Agents for distributed task execution. Nx Cloud splits one pipeline across many machines using the Nx task graph. Cachely does not run tasks at all.
• You rely on self-healing CI. Nx Cloud can propose fixes for failing tasks. There is no equivalent in Cachely.
• You use the Nx Cloud run views every day. Flaky-task detection, pipeline timelines, and CI analytics are part of the platform, not the cache.
• You need Nx Enterprise features. SSO and SAML, single-tenant or on-premises deployment, conformance rules, and code owners are on Nx Cloud Enterprise.
• You fit inside the Hobby plan. A small team running fewer than about 100 pipelines a month pays nothing, and qualifying open-source projects are free.

If none of those describe you, you are paying a platform price for one feature of the platform. That is the case this page is for. If you are not sure what the cache saves you in the first place, the remote cache overview explains how it works across tools.

Nx Cloud vs Cachely pricing (checked 7 October 2026)

Nx Cloud bills in credits. Every CI pipeline execution (CIPE) costs 500 credits whether or not it uses Nx Agents, and Agents and self-healing CI consume more on top. The Team plan also charges for each contributor - anyone who authored the commit of a CI pipeline execution in the billing cycle - beyond the five included. Cachely charges a flat monthly price and limits storage and cache requests instead of people.

Worked examples: 5, 15, and 40 developers

List prices are hard to compare, so here is what a cache-only Nx Cloud Team bill works out to for three team sizes. These are estimates built from the published prices above, with these assumptions:

• Cache only: no Nx Agents, no self-healing CI, so each pipeline costs exactly 500 credits.
• 40 CI pipeline executions per developer per month - roughly two pushes per working day.
• Every developer authors CI commits, so every developer is a contributor.
• Up to 10 concurrent CI connections, except 20 for the 40-developer team.

Your own numbers will differ. Push more often and the Nx Cloud credit line grows; use Agents and it grows faster. On Cachely the figure that matters is cache requests (reads plus writes), not people, so the last column shows how many requests per pipeline the Team plan's 3,000,000 a month leaves room for.

Feature matrix

The short version of what each product covers. For every row with more detail, see the full Cachely vs Nx Cloud comparison.

Your options

• Stay on Nx Cloud if you use Agents, self-healing CI, or the run analytics, or need Enterprise deployment options. The cost buys real capability.
• Move the cache to Cachely if the cache is the only part you use. The price stays flat as the team grows, and the same workspace also serves Turborepo, Gradle, and Bazel. See the plan limits.
• Run your own cache. Nx documents an OpenAPI spec that any cache server can implement, and open-source servers exist. You trade the subscription for hosting, patching, and access control. The trade-offs are covered in Cachely vs a self-hosted Nx cache, and the move off bucket-backed caches in the deprecated Nx cache package migration guide. Avoid the deprecated @nx/s3-cache, @nx/gcs-cache, and @nx/azure-cache packages: they are exposed to the CVE-2025-36852 cache-poisoning attack and will not be patched.
• Turn the remote cache off. Nx still caches on each machine. For a small repository where CI is already fast, that can be enough, and it costs nothing.

Migrating in two environment variables

Cachely implements the remote cache API that Nx already supports, so there is no plugin to install. Create a workspace and a token, then set two variables wherever Nx runs:

NX_SELF_HOSTED_REMOTE_CACHE_SERVER=https://remote.cachely.dev
NX_SELF_HOSTED_REMOTE_CACHE_ACCESS_TOKEN=<your-token>

• Disconnect the workspace from Nx Cloud by removing nxCloudId (or nxCloudAccessToken) from nx.json, so CI talks to one cache.
• Give pull-request and fork builds a read-only token so they can read the cache but never write to it. That closes the cache-poisoning path described on the security page.
• Run the pipeline twice: the first run fills the cache, the second should show remote cache hits.

What each variable does, and the trailing-path mistake to avoid, is in NX_SELF_HOSTED_REMOTE_CACHE_SERVER explained. CI secrets and verification steps are in the docs, and the wider field is on the comparisons hub.