The cache trust model

Cachely receives the outputs and content hashes that your configured cache client sends. There is no GitHub App 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.

Managed artifacts are content-addressed and immutable. Once a cache key exists it cannot be overwritten - the API returns 409 on a re-write of an existing key. A known-good build can never be silently replaced by a later one claiming the same hash.

Immutability plus read-only tokens for untrusted builds is precisely what closes the CVE-2025-36852 (CREEP) cache-poisoning attack. We wrote up how that attack works and why these two controls stop it: 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.
• Cache keys are content-hashed, so changing a task's inputs produces a new key. Stale results are never served, and there is no manual purge to get wrong.

Caching is an optimization, never a dependency in the critical path. A miss, an outage, or an over-quota workspace returns a 404, and your build tool simply runs the task locally and re-uploads when it can. There is no failure mode in which Cachely being unavailable stops your build from completing.