Share a dependency cache across development machines and CI
Compare local package caches, CI caches, and Depsilo shared dependency caching, then use one project to evaluate repeated downloads and operating costs.
A shared dependency cache is worth testing when development machines, temporary CI runners, or new servers repeatedly download the same dependencies. Depsilo routes their dependency requests through a self-hosted instance so later requests can reuse downloaded content.
The benefit depends on downloads your existing caches still leave unresolved, and the network path to the instance. This guide covers stable v0.11.0 and helps you evaluate it with one project.
What each cache does
Section titled “What each cache does”| Approach | What it stores | Reuse scope | Prerequisites |
|---|---|---|---|
| Package-manager local cache | Client-managed metadata, downloaded files, or content storage; details vary by client | Install tasks that can access the same cache directory | The directory persists and the client can reuse its contents |
| CI cache | Files from workflow-selected paths, potentially including package caches or build outputs | Jobs allowed to restore the corresponding cache | Correct paths, cache keys, and restore conditions; usable content is actually restored |
| Depsilo shared dependency cache | Dependency metadata and artifacts requested and cached through the instance | Development machines, servers, and CI configured to use that instance | Clients can reach it, requests arrive, and content is cacheable and remains eligible for delivery |
All three can coexist. CI can restore a package manager’s local cache first; requests that still need a registry can then reach Depsilo. Keep existing caches enabled.
A read fully satisfied by a local cache never reaches Depsilo. The same install may still request metadata or other artifacts. A successful or faster second install alone does not prove a server cache hit.
When a shared cache can help
Section titled “When a shared cache can help”- Temporary environments repeat downloads. Runners or virtual machines are frequently replaced, and existing CI caches do not restore all the needed packages.
- Machines have overlapping dependencies. Each has its own local cache but independently downloads packages on first use.
- You need visibility into requests reaching the service. Shared access logs or centrally enabled package policies can also justify a proxy. They cover only requests passing through it.
When local or CI caches already eliminate most downloads, there may be little download benefit. A distant instance, slow storage, or limited bandwidth can add waiting time. Locate the repeated downloads before committing to running a service.
Separate download caching from build speed
Section titled “Separate download caching from build speed”Metadata helps clients select versions and locate downloads; artifacts are the package files themselves. Their cache lifetimes and request patterns differ. A metadata hit does not establish an artifact hit, and cached content must still satisfy applicable policy and validation requirements.
Installation can also involve extraction, install scripts, and native extension compilation. Builds may spend time compiling source or running tests. More efficient download delivery does not imply a proportional improvement in whole-build time. Measure request duration and total job duration separately.
Reusing compilation results is another layer. Depsilo’s ccache / sccache compiler cache requires separate configuration. Connecting a package manager does not enable it, and it does not execute compilation jobs for you.
Try one project before expanding
Section titled “Try one project before expanding”- Prepare a reversible trial. Start with the quick start. For other devices, configure a reachable address and HTTPS. A remote client’s
localhostrefers to that client. - Connect one representative project. Save its existing registry, index, or source settings. Follow the package-manager guide, prefer project-level configuration, and preserve lockfiles and integrity checks.
- Confirm real requests. Use the cache verification guide to send artifact requests independently of the package manager’s local cache. Match them in Admin → Access logs and check whether repeated requests hit. The first request may already hit existing cached content.
- Measure your workload. Compare direct and proxied download times, upstream traffic, and total job time using representative dependencies. Hold the project version, lockfile, and client-cache state constant. Repeat measurements and record network and storage conditions.
- Test rollback. Restore the saved source settings and confirm a normal install works before connecting more machines. Rollback does not require deleting lockfiles or adding parallel public sources.
What running it involves
Section titled “What running it involves”A shared cache needs persistent state, capacity management, backups and restore procedures, upgrades, and client connectivity with TLS. S3 can hold cache objects; configuration and SQLite still need durable local storage. See the deployment guide.
v0.11.0 supports a single instance. Multiple instances sharing a database for high availability are unsupported. An unavailable instance affects requests that still need it, so include recovery or restoring original sources in your trial.
It is not a complete offline mirror. Uncached dependencies still need upstream access; delivering cached content depends on metadata, validation, and policy conditions. One successful warm-cache install does not establish that every install and build will work offline.