Multiple repositories do not have to mean multiple cache budgets. In Cachely, workspaces keep artifacts and tokens separate, while storage and monthly cache operations add up across the workspaces an account owns. Here is how to use those boundaries to plan capacity and investigate growth.
Separate the isolation boundary from the budget boundary
A workspace is a cache namespace. Its tokens resolve to that workspace, and an artifact written for one workspace is not visible to another. This is the boundary to use when repositories should not share task outputs, when a service needs its own token lifecycle, or when an environment needs its own operational view.
In Cachely, plan limits apply to the workspace owner's account. Every workspace they own contributes to the same storage and monthly operation totals; creating another workspace does not add another allowance.
For an illustrative example, suppose repository A retains 3 GB in one workspace and repository B retains 2 GB in another. The account uses 5 GB of storage, while each repository's artifacts remain isolated. Their cache operations also add up toward the account's monthly allowance.
- Workspace: artifact namespace, token scope, repository-level setup, and a useful breakdown for investigation.
- Account: subscription, storage total, and monthly cache-operation total across the workspaces it owns.
- Token: a specific credential with read-only or read-write permission, issued for a person, CI job, or automation rather than shared everywhere.
Budget storage and cache operations separately
Remote-cache capacity is easier to reason about when storage and operations stay separate. Storage answers, "How much data is currently retained?" Operations answer, "How much cache work is this CI fleet producing this month?" A build that restores many small tasks can use many operations without occupying much storage. A large generated artifact can do the opposite.
Storage is a retained footprint, not historical uploads
Watch the retained cache footprint rather than adding every upload ever made. Rebuilding the same immutable cache key should not make the footprint grow, but a stream of unique large outputs will. The most useful workspace breakdown asks which repository owns the retained bytes and which tasks are continuously creating new cache keys. That is a signal to revisit outputs, inputs, or retention expectations before deleting a whole cache. For a deeper diagnosis, see our guide to cache storage limits and churn.
Cache operations measure activity
Reads, misses, existence checks, and writes contribute to cache activity. An HTTP request can include several operations: a batched existence check probes multiple cache keys. A sudden jump often means a workflow now runs more matrix jobs, new automation is using the same account, or a miss pattern is causing repeated checks. Start with the account-wide trend, then use workspace and token breakdowns to locate the pipeline responsible. A healthy cache can be busy; the question is whether the traffic is producing useful reuse.
Choose workspaces for ownership and access
Use a separate workspace when it provides a real operational or security boundary:
- A repository needs tokens that can be revoked without affecting another repository.
- An experimental project needs a separate cache namespace.
- A platform team wants a distinct usage and hit-rate view for a product area.
Make CI behavior safe when a limit is reached
When an upload would exceed your storage allowance, Cachely skips storing it. Existing cached artifacts remain available while your monthly operation allowance permits reads. Once that operation allowance is exhausted, remote reads behave as cache misses and new uploads are skipped. Tasks without a usable local cache entry execute normally, so quota enforcement can make a build slower without making the quota itself a build error.
Treat that graceful fallback as a safety net, not your normal operating mode. Give trusted CI builds a read-write token to publish known-good artifacts. For pull requests and forks that are allowed to read the workspace's outputs, use read-only tokens. These cannot upload artifacts or consume additional storage, but their reads still use the monthly operation allowance. Our workspace and token setup guide walks through that split in more detail.
A monthly cache-capacity review
Use this short review before a larger release cycle or when the usage meter changes faster than expected:
- Check the account total first: retained storage and cache operations for the current month.
- Identify the workspaces responsible for a meaningful change; do not infer it from repository size alone.
- For storage growth, inspect whether large generated outputs are truly cacheable and whether tasks declare only the outputs they need. Our Nx inputs and outputs guide is a good starting point.
- For operation growth, compare CI matrix changes, retry behavior, and new tokens or automation.
- Keep untrusted builds read-only, then revise the plan or cache design before a limit becomes routine.
Review storage and operations alongside cache hits and time saved. That helps distinguish useful growth from a pipeline that produces more traffic without avoiding more work. The remote build cache guide explains how reuse fits into the broader CI workflow.