A cache accurate enough that your team actually trusts it
As a startup building this ourselves, we didn't want a cache that occasionally served stale output and quietly trained the team to disable it. Infrovel's cache is content-addressed, so a hit means the output really would have been identical.
It sits underneath whatever build tool you already use, and it's shared the moment it's turned on — the second developer to touch an identical change, whether that's a teammate or a CI run an hour later, gets the cached result instead of paying full price again.
Get started freeWhat teams actually notice first
A cache hit is based on actual file and environment inputs, not a timestamp you have to trust
Shared across every contributor and every CI run, so the second person to touch a change never pays full price
Works underneath your existing build tool — nothing to migrate, nothing to configure per project
A visible hit rate per run, so you can tell at a glance whether caching is actually helping
What actually determines a cache hit
When a task runs, Infrovel records every file it reads, every environment variable it depends on, and the command used to invoke it. Those inputs are hashed together into a single cache key — not the task's name, not a timestamp, and not a version number someone has to remember to bump.
The next time a task runs with a cache key that already exists, the stored output is restored instead of re-executing the task. If even one input byte differs — a dependency bump, a changed source file, a different environment variable — the key changes too, and the task runs for real.
That's the property that makes the cache something a team can leave on by default rather than something they reach for cautiously: a hit is never a guess about whether the output is still valid, it's a guarantee derived from the actual inputs.
Cache FAQ
Cache keys are derived from every file and environment variable a task declares as an input. If any of those change, it's a cache miss — there's no manual invalidation list to maintain or forget about.
In isolated, per-workspace storage — nothing is pooled or shared across different customers' workspaces, including on the free beta tier.
Your pipeline falls back to building normally. The cache is a performance layer, not a dependency your builds rely on to function.
Not yet — it's on our roadmap. If this is a blocker for you, tell us on a call, since it directly shapes what we prioritize next as a startup.
Environment details that affect the output — OS, architecture, tool versions — are part of the cache key, so a task run on an ARM runner won't incorrectly reuse output built for x86, or vice versa.
Yes, both for a single task's cache entries and for the whole workspace, from the dashboard or the CLI. In practice this is rarely needed, since correctness is enforced by the input hash rather than by trust.