The cache trust model

Cachely receives the outputs and content hashes that your configured cache client sends. Signing in with GitHub uses a GitHub App that reads only your email address, with nothing to install and no repository permission to grant. You connect with a server URL and token, so the trust boundary is a scoped cache credential rather than access to your repo. If declared task outputs include source or source-derived files, those files are part of the artifact.

That means a compromise of Cachely exposes cached build artifacts, not repository access, git history, or CI credentials.

• Requests carry a Bearer token. Tokens are stored hashed (SHA-256) and shown in full only once, at creation.
• An unknown or revoked token is rejected with a 401 before any storage is touched. Revoking a token cuts access instantly and does not affect any other token.
• Each token is scoped to a single workspace. Issue one per CI pipeline, repo, or developer so you can rotate or revoke any of them in isolation.
• Token scope is fixed at creation as read-only or read-write and enforced server-side. A leaked read token cannot be escalated to write.

Untrusted builds - pull requests and forks - should read the cache to stay fast but must never write to it. That is the whole defense against cache poisoning, and Cachely enforces it at the API rather than trusting the client.

Nx, Turborepo, Gradle, and Bazel CAS artifacts are write-once. Existing objects are not replaced. Nx returns 409 for a duplicate key; other clients may receive an idempotent success response. Bazel action-cache entries can be replaced by an authorized writer to allow stale results to be repaired.

Read-only tokens prevent untrusted builds from uploading artifacts, while write-once storage prevents replacement of existing Nx keys. Both controls matter when addressing CVE-2025-36852 (CREEP). Trusted writers and correct task inputs remain part of your security model. Read the Cache poisoning and CVE-2025-36852.

Every workspace has its own storage prefix, and artifacts are keyed under it. A token resolves to exactly one workspace, so one workspace can never read or write another workspace's cache - there is no shared namespace to collide in or enumerate across.

• Managed artifacts live on Cloudflare R2. All traffic is served over HTTPS (encrypted in transit) and R2 encrypts objects at rest by default.
• Cachely stores build outputs and their content hashes, plus cache event metadata - which task, which token, hit or miss - used for the ROI and insight reporting.
• Automated analysis reads limited artifact structure, paths, metadata, and task-output prefixes to label customer-facing insights. Authorized maintainers may inspect the minimum necessary data for support, security, or debugging; customer-specific contents and insights are not published or used for model training.
• Managed cache objects auto-expire after a retention window (currently 20 days from upload), so idle artifacts do not linger. Anything still in use is simply re-uploaded on the next run.
• Build tools derive cache keys from task inputs. Correctly declared inputs and deterministic outputs are necessary for valid reuse; an omitted input can cause stale results even when the cache protocol is working correctly.

A cache miss returns 404 so the client can execute the task locally. Network outages, authentication errors, retries, and timeouts can behave differently depending on your build tool and configuration. Test unavailable-cache and quota-limit behavior in your own pipeline before rollout. The troubleshooting guide covers common client symptoms, and the status page reports current service probes.