Cloudflare-native Turborepo remote cache

Turboflare

A fast, self-hosted remote cache backed by Workers and R2. One token to start. Zero servers to manage.

Worker + R2default architecture
Turbo-compatiblestandard remote cache
0 serversno infra to manage

Everything you need

R2 artifact storage

Durable cache artifacts in your Cloudflare account.

Works with Turbo

Use standard Turbo remote cache env vars. No client fork.

Flexible auth

Start with one token. Add scopes and teams later.

Edge-fast reads

Serve repeated reads from nearby Cloudflare PoPs.

Branch isolation

Share main cache safely without trusting every PR.

Signature enforcement

Require signed uploads when CI needs stricter integrity.

Ops built-in

Retention, cleanup, stats, purge, and metrics hooks.

One-click deploy

Deploy Worker + R2, set a token, point Turbo at it.

Why Turboflare

Turborepo remote cache should be boring infrastructure: deploy it, set a token, point CI at it, and move on.

Alpha

Turboflare is still in the works. Expect rough edges and breaking changes.

Turboflare request flow

Quick context:

  • Turborepo hashes each task from inputs, command, env, and outputs.
  • Remote caching lets one runner upload a task result and another runner restore it.
  • This matters most in CI because fresh runners usually start with no local cache.

Measured in Turboflare's own CI run 27145453178:

CI step Time Meaning
no remote cache 95s rebuild everything
cold Turbo seed + upload 94s compute once, store artifacts
remote-cache rebuild 2s restore matching task hashes

Thanks to Vercel for making Turborepo and the remote cache protocol easy to use and self-host. If Vercel Remote Cache fits your project, use it. Turboflare is for teams that specifically want the cache Worker and artifacts in their own Cloudflare account.

Need Turboflare gives you
Fast global reads Cloudflare Workers + optional Cache API
Durable artifact storage R2 as source of truth
Simple auth static tokens, scoped tokens, optional D1 tokens
Ops control R2 lifecycle, bounded cleanup, internal purge/stats
Turbo support standard remote cache behavior, no client fork

See the Feature Matrix for the complete implemented feature list.

If this sounds like your team

You have... Turboflare helps by...
PRs rebuilding the same packages restoring cached Turbo tasks from Cloudflare.
cache data that must stay in your org keeping artifacts in your R2 bucket with your own tokens.
open-source forks or untrusted PRs pairing read-only tokens with branch-aware cache policies.
teams split across regions serving repeated reads from nearby Cloudflare PoPs.
too much infra for a build cache replacing cache servers with one Worker and one R2 bucket.
client projects that cannot share data namespacing each repo, customer, or branch independently.

Choose a setup path

Path Use when Start here
Clone-free setup you want Wrangler to ask and fill values Getting Started
Agentic setup you want an AI coding agent to do it safely Agentic Setup
Manual setup you want every Cloudflare step explicit Deploy
Terminal
pnpm dlx create-turboflare

The shortest manual version

Terminal
pnpm install
pnpm deploy
wrangler secret put TURBO_TOKEN --config apps/cache-worker/wrangler.jsonc
Terminal
export TURBO_API="https://<worker-name>.<subdomain>.workers.dev"
export TURBO_TOKEN="<same token>"
export TURBO_TEAM="team-name"
turbo run build --cache=local:,remote:w
rm -rf .turbo
turbo run build --cache=local:,remote:r

Turboflare stores Turbo task cache artifacts. It does not deploy your application code.

Where to go next

If you want to... Read this
deploy the Worker Deploy
configure Turbo clients Turbo Client Setup
understand the system shape Architecture
tune R2 and cleanup Storage & Retention
set up teams and tokens Auth & Teams
operate production Operations