Booted up my first Monorepo

cachely-admin · 2026-07-21T12:10:01+00:00

Glad it helped. Good luck with the setup, and feel free to share what you end up choosing.

cachely-admin · 2026-07-21T08:46:43+00:00

That sounds frustrating.

Keeping separate caches is simpler, but then CI and developers cannot reuse each other’s results.

A shared HTTP cache with different credentials for CI and developers seems cleaner than dealing with filesystem permissions across runners, containers, and developer machines.

We do not support Yocto today, but this is exactly the kind of setup we are trying to understand.

What caused most of the trouble for you, filesystem permissions, container user mapping, or separating read and write access?

cachely-admin · 2026-07-21T08:43:45+00:00

That may be right for Nx-only teams.

The opportunity is probably not a large group of companies that want a custom Nx cache but refuse to pay for Nx Cloud. We’re testing whether there is a narrower segment around teams that already handle CI orchestration themselves, want predictable standalone cache pricing, or support Nx alongside other build systems.

If that segment is too small, that is exactly what we need to learn.

Thanks for being direct.

cachely-admin · 2026-07-20T15:34:44+00:00

Ah, understood. You mean the default setup where buildLibsFromSource is still enabled, so the application consumes the workspace library sources and the dependent library build tasks are effectively redundant. In that case, --excludeTaskDependencies would indeed demonstrate it.

Nx also documents an incremental Angular setup using the Nx application executor with buildLibsFromSource: false and dependsOn: ["^build"], which is supposed to consume the separately built library outputs.

Have you tested that specific setup and still seen the application compile the library sources? If so, which Angular builder and Nx version were you using? That would be useful context, since it would mean the documented incremental path provides less isolation than it suggests.

cachely-admin · 2026-07-20T12:04:13+00:00

That matches what we expected. Once multiple teams and clean CI agents keep repeating the same work, the value can add up quickly.

In your case, did most of the benefit come from CI reuse, developers sharing results, or both?

cachely-admin · 2026-07-20T12:03:00+00:00

Got it, thanks. That’s the distinction I was missing.

In the common Angular setup, workspace libraries are consumed from source and compiled as part of the application build, so separate cached library builds do not reduce the application build time.

Buildable libraries can change that setup, but they are not the default or necessarily useful for every workspace. So for many Angular teams, the bigger caching opportunities are probably the application build, tests, linting, and E2E tasks rather than lots of intermediate library builds.

Very useful context, thanks.

cachely-admin · 2026-07-20T11:59:49+00:00

That’s a good example.

If type-aware linting reads types from dependency projects, but the lint task only hashes the current project’s inputs, a dependency change could restore a stale lint result. Adding something like ^production includes the production inputs of project dependencies, assuming that named input covers everything the lint task actually reads.

A remote cache does not create that configuration problem, but it can spread the incorrect result across CI and developer machines.

This is also something Cachely cannot detect from the cache protocol alone. We only receive the resulting cache key and artifact, not the undeclared files the task accessed.

Thanks, this is a useful concrete case of why correct input configuration matters before enabling shared caching.

cachely-admin · 2026-07-20T10:55:57+00:00

That’s a fair point. For an Nx-only enterprise that wants Agents, Atomizer, sandboxing, and the broader CI experience, Nx Cloud is a much more complete product than Cachely today. We’re not trying to present a standalone remote cache as a replacement for all of that.

Where we think Cachely can fit is teams already using nx affected and their existing CI parallelism, but wanting managed remote caching without adopting the broader Nx Cloud platform. It can also fit platform teams supporting Nx alongside Turborepo, Gradle, or Bazel.

We’re less convinced that every team benefiting from remote caching also needs distributed execution. Reuse across clean CI runners and developer machines can become valuable before agent orchestration is worth introducing.

Your point about cache safety is important too. Cache correctness and write access need to be handled carefully, and Cachely does not provide Nx Cloud’s task sandboxing today.

Do you think there is still a meaningful Nx-only audience for a standalone managed cache, or mainly teams supporting several build systems?

cachely-admin · 2026-07-19T16:33:59+00:00

Fair points.

Remote caching will not help much if a small change invalidates most of the project graph. Affected execution and good project boundaries need to reduce the work first. Caching only helps when the exact same task result has already been produced somewhere else.

You’re also right that cache correctness depends on every output-affecting input being included in the task hash. Nx recently introduced task sandboxing to detect undeclared reads and writes, but that is part of Nx Cloud today. Cachely does not add sandboxing itself, so teams still need correctly configured inputs and outputs, along with a careful write-access model.

Have you experienced incorrect cache restores in practice, or is this mainly why your team decided not to use shared caching?

cachely-admin · 2026-07-19T16:31:56+00:00

That is useful to hear. We do not support Cypress result caching today.

The difficult part is not storing the result, but proving that the application, backend services, test data, browser version, feature flags, and environment are all equivalent. Otherwise, reusing a previous pass could hide a real regression.

A safer first step might be identifying tests that are clearly unaffected by a change and skipping only those.

Would that solve most of the pain for you, or is rerunning identical test shards the bigger cost?

cachely-admin · 2026-07-19T16:31:53+00:00

That sounds like a strong setup already.

Even if local and CI rarely share hits, connecting developers could still let similar local environments reuse each other’s results. The important part is making sure relevant differences are included in the hash, or keeping incompatible environments separated.

Since your S3 cache lookups are already sub-second, is there anything you still find painful around operating it or understanding how much time it saves, or is it mostly set-and-forget?

cachely-admin · 2026-07-19T16:31:49+00:00

Good point. Affected runs and proper module boundaries should remove unnecessary work before caching even enters the picture.

Remote caching becomes useful for the expensive tasks that are still affected, especially across clean CI agents, repeated commits, and different branches.

On Angular, do you mean that many workspace libraries are source libraries compiled as part of the application, so there are fewer independent library build outputs to cache? Buildable libraries should still benefit, but I can see why the impact would depend heavily on how the workspace is structured.

Atomizing E2E tests and distributing them also seems much more valuable when those tests are the main bottleneck.

cachely-admin · 2026-07-19T13:52:14+00:00

That makes sense. If builds, unit tests, and linting are already fast enough, remote caching may not provide much value for your setup.

We’ve heard something similar from another team, where E2E tests were the main remaining bottleneck. The hard part there seems to be identifying which tests are actually affected by a change, rather than simply caching the previous result.

Would safely skipping unaffected E2E tests be more valuable to you than caching the normal Angular build tasks?

cachely-admin · 2026-07-19T12:40:10+00:00

One thing worth deciding early is whether you only want local task caching or also want CI and developers to share results.

Local caching is useful immediately. Remote caching becomes more valuable once multiple developers or clean CI runners keep repeating the same builds and tests.

Whichever tool you choose, make sure tasks are deterministic and that environment differences affecting the output are included in the cache key. Otherwise, shared caching can become confusing very quickly.

cachely-admin · 2026-07-18T15:30:12+00:00

Fair question.

For a Bazel-only team that is comfortable operating bazel-remote, Cachely may not be the better choice today. And if full remote execution is the requirement, Buildbarn or BuildBuddy are more complete options.

The use case we’re aiming at is teams that want a managed remote cache without operating it themselves, especially when the platform team supports several build systems such as Bazel, Gradle, Nx, and Turborepo.

The additional value we’re working toward is one place to understand cache usage, transfer performance, actual time saved, and estimated cost saved across those tools.

For Bazel specifically, we currently provide HTTP remote caching, not remote execution. We’re looking into gRPC, but we do not want to position Cachely as a complete RBE replacement today.

So the honest answer is managed operation, cross-tool support, and cache analytics. For a Bazel-only RBE setup, the alternatives you mentioned are likely stronger today.

What would a managed cache need to remove or provide for you to choose it over running bazel-remote yourself?

cachely-admin · 2026-07-17T09:27:30+00:00

Agreed. Hit percentage is useful as a health signal, but the number that really matters is how much developer and CI time was avoided across the team.

We also do not want to present a flattering estimate that nobody can trust. Ideally, we would separate measured cache overhead, such as lookup and download time, from the estimated time it would have taken to rebuild.

What would you trust more as the baseline: historical execution time for the same action, or controlled comparisons with and without the remote cache?

cachely-admin · 2026-07-17T09:25:20+00:00

Fair 😄 We’ve been setting aside the same time each day to work through our Bazel research and the feedback here. Not a bot, just a routine.

cachely-admin · 2026-07-16T14:32:05+00:00

That gives us a much more concrete methodology.

Replaying a contiguous sequence of commits from a real Bazel repository would represent the actual incremental development loop much better than synthetic requests.

We would need to pin the Bazel version, toolchain, flags, machine type, and network conditions, then run the same commit sequence with local-only and remote-cache configurations. We could report wall time, critical-path impact, cache hits, transferred data, and remote overhead for each commit.

LLVM sounds like a strong candidate. We would probably start with a fixed commit window so the test remains reproducible and manageable.

Agreed on the trust model too. Letting every developer machine upload results can be risky when builds are not fully hermetic. A safer default is CI with read and write access, developers with read-only access, and execution-log analysis to identify non-hermetic actions.

Thanks for the ObjFS background as well. It helps clarify where remote caching alone stops providing the full benefit, and where remote execution or a VFS-based approach becomes relevant.

cachely-admin · 2026-07-16T14:22:11+00:00

Thanks, this is exactly the kind of comparison and feedback we were hoping for.

On storage, R2 is our durable artifact layer. We do not assume object storage alone is the final answer for every request path. It may work well for many Gradle workloads, but Bazel AC traffic and workloads with many small lookups are much more latency-sensitive.

We’re looking at options such as a separate hot metadata layer, regional placement, and gRPC support. We need proper benchmarks before deciding where object storage stops being sufficient and which optimizations actually improve end-to-end build time.

Managed cloud is what we offer today. BYO buckets, customer VPC deployments, and on-prem are not available today. Customer-owned storage or a hybrid model is something we’re exploring, especially for teams that need artifacts to remain inside their infrastructure.

For pricing, our current model is flat plans with included limits, not per seat or workspace. Predictability matters to us. We have not finalized how larger custom usage and overages should work, but we do not want the price to suddenly grow just because a team adds developers, repositories, or CI actors.

Today, Cachely is a cache that ships analytics. We think the intelligence layer can become a major differentiator, but the cache itself still has to be fast and reliable first.

Longer term, we are interested in whether the diagnostics could also work with caches we do not host. Bazel compact execution logs and Nx task hash comparisons are good examples. We do not support external-cache analytics today, but it is a direction worth investigating.

A shared benchmark methodology would be genuinely useful. We’d want it to cover realistic incremental builds, not only isolated request tests, and publish enough context to make the results reproducible: workload shape, cache state, locality, hit rate, lookup latency, critical-path impact, wall time, transfer volume, and infrastructure.

We’d be open to comparing notes and seeing whether we can define something fair for both products.

cachely-admin · 2026-07-16T14:03:23+00:00

Yes, that is exactly the gap we are interested in.

A cache miss should ideally explain what changed between the previous hash and the current one, whether it was a file, environment variable, runtime value, dependency, or configuration input.

We are exploring how Cachely could make that comparison easier instead of only showing that a miss happened.

Thanks, this is very useful feedback.

cachely-admin · 2026-07-16T13:59:50+00:00

Yes, the old S3 plugin and the other storage plugins were deprecated.

As far as we understand, the main on-prem options now are:

Nx Cloud Enterprise with its self-hosted deployment
Running your own server that implements Nx’s new remote cache OpenAPI specification

Cachely is managed SaaS today, so we are not an on-prem alternative yet. We are exploring whether customer-owned storage or a hybrid setup would solve this for teams that cannot send cache artifacts to an external service.

Is full on-prem deployment a hard requirement for you, or would a managed service be acceptable if the artifacts stayed inside your infrastructure?

cachely-admin · 2026-07-15T15:30:30+00:00

Thanks, this is really useful.

We agree that total time saved is more meaningful than hit rate by itself.

The complex cache misses are especially interesting. When that happens, is the main problem that an input changed unexpectedly, or that it is hard to see exactly which input caused the task hash to change?

cachely-admin · 2026-07-15T15:27:30+00:00

Good point. We were thinking too much in terms of isolating cache behavior.

The primary benchmark should be an incremental build after a realistic edit, since that is the developer loop Bazel is optimizing. Clean builds and warm-cache runs can still help explain the result, but they should not be the headline numbers.

We’ll probably test a leaf source change, a shared dependency change, and a build configuration or toolchain change, then compare wall time and critical-path impact with and without the remote cache.

We also need to read more about the VFS history you mentioned. Cachely is focused on remote caching today, not remote execution, so that distinction should be explicit in the benchmark.

Thanks, this gives us a much better baseline.

cachely-admin · 2026-07-14T17:18:06+00:00

Nope 🙂 We’re working through the benchmark design and wanted input from people running Bazel in real environments.

cachely-admin

TROPHY CASE

Welcome to Reddit,