finds.dev← search

// the find

ducktors/turborepo-remote-cache

★ 1,456 · TypeScript · MIT · updated Jun 2026

Open source implementation of the Turborepo custom remote cache server.

A self-hosted implementation of Turborepo's remote cache API, so you can run your own cache server instead of paying Vercel. It's a Fastify app that speaks the Turbo cache protocol and backs it with whichever storage you already have — S3, GCS, Azure Blob, local disk, or MinIO. Teams running Turborepo on-prem or in air-gapped environments will find this is the only real option.

Storage abstraction is genuinely broad — S3, GCS, Azure Blob, local, and MinIO are all first-class, not afterthoughts. The auth layer supports both static tokens and JWT, which covers the 'one shared secret' case and the 'per-team tokens' case without extra config. Deploy story is well thought out: Docker image, one-click DigitalOcean App Platform, Lambda handler, Cloud Run docs, and a Vercel adapter all exist. Test coverage is per-storage-provider, so you can actually trust the S3 and GCS paths rather than hoping they work like local.

The Turborepo remote cache protocol is intentionally underdocumented by Vercel, so this project is essentially reverse-engineered and can break when Turbo ships a protocol change — there's no versioning contract on that side. Cache eviction is primitive: local storage has a clean endpoint, but for S3/GCS you're expected to configure lifecycle rules yourself, which is fine but means cache bloat is your problem. No metrics or observability out of the box — you're flying blind on hit rate, artifact sizes, or whether the server is actually saving CI time. The auth model has no rate limiting or abuse protection; a leaked token means your storage bill is someone else's problem.

View on GitHub → Homepage ↗

// want more like this?

We dig through GitHub every week and send a few repos picked for what you actually care about — each with an honest take like this one.

Get finds in your inbox → Search again →