The Complete Production SOP: How to Deploy and Run Turborepo Remote Caching with Self-Hosted S3 / MinIO in Autonomous AI Agents
Step-by-step SOP for Turborepo remote caching with self-hosted S3/MinIO in Codex, Claude Code, and Cursor. Slash CI build times up to 85% with FULL TURBO hits.
Technical Overview & Architectural Context
Autonomous coding agents frequently stumble when optimizing monorepo build pipelines. Without deterministic procedural boundaries, agents commonly make critical mistakes: omitting required artifact declarations in `turbo.json` outputs (such as forgetting `.next/cache/**` or `dist/**`), generating unauthenticated cache URLs, hardcoding AWS S3 credentials into tracked source files, or failing to differentiate between local build caching and authenticated remote cache servers. This results in cache misses, broken incremental deployments, and CI build timeouts. The `turbo-remote-cache-s3` skill forces autonomous agents (Codex, Claude Code, Cursor, Windsurf) to adhere strictly to hardened infrastructure patterns. It establishes standard SOPs for deploying open-source cache servers (such as `ducktors/turborepo-remote-cache`), binding S3 or MinIO buckets via IAM/S3 compatible API keys, ensuring correct task output globbing, and injecting runtime secrets via environment variables rather than project configurations. This eliminates token waste on speculative build debugging and ensures deterministic 'FULL TURBO' execution in both local development and CI/CD pipelines.
Prerequisites & Environment Requirements
Verified Search Intents & Long-Tail Queries Solved
This operational tutorial is engineered to provide deterministic solutions for these developer search queries:
Step-by-Step Execution Playbook
Local Environment Setup & SKILL.md Mounting
Mount the skill manifest into your agent's runtime directory to establish procedural boundaries.
Autonomous agents discover custom toolings and procedural SOPs by inspecting skill descriptors in their dedicated runtime directories. By injecting the `turbo-remote-cache-s3` specification into the workspace or runtime configuration (`~/.claude/skills/`, `.cursor/skills/`, or `~/.agents/skills/`), agents automatically ingest deterministic boundaries for remote caching before executing any build modifications.
mkdir -p .agents/skills/turbo-remote-cache-s3 && curl -fsSL https://askills.dev/api/skills/turbo-remote-cache-s3/raw -o .agents/skills/turbo-remote-cache-s3/SKILL.md---
name: "turbo-remote-cache-s3"
description: "Share build and test computation caches across developers and CI using Turborepo Remote Cache."
metadata:
author: "Vercel"
version: "1.0.0"
runtime_compatibility:
- "codex"
- "claude-code"
- "cursor"
- "windsurf"
triggers:
- "setup turborepo remote cache s3"
- "configure turbo.json outputs"
- "slash ci build time turbo"
permissions:
fs_read: true
fs_write: "workspace"
shell_exec: false
net_access: false
---
# Turborepo Remote Caching with Self-Hosted S3 / MinIO
Configures Turborepo Remote Caching: running custom remote cache servers (turborepo-remote-cache) backed by AWS S3 or MinIO, configuring turbo.json outputs and dependencies, and slashing CI times by up to 85%.Scope the skill to `.cursor/skills/` or `.claude/skills/` in your repository root so team members and CI bots inherit the same remote cache SOP automatically without context duplication.
Ensure `fs_write` is limited to the workspace. Do not grant broad filesystem write access outside the monorepo root to avoid inadvertent overwrite of global Turbo configs (~/.turbo).
Deploying the Remote Cache Server & turbo.json Configuration
Instruct the agent to scaffold the self-hosted cache server deployment and validate task outputs.
Turborepo requires a standard Vercel-compatible remote cache HTTP API. We configure the agent to declare the `ducktors/turborepo-remote-cache` service in a Docker Compose configuration (or Helm/K8s manifest) targeting S3 or MinIO, while rigorously tuning `turbo.json` task outputs to guarantee artifact persistence.
cat << 'EOF' > docker-compose.turbo-cache.yml
version: '3.8'
services:
turbo-cache:
image: ducktors/turborepo-remote-cache:latest
environment:
- NODE_ENV=production
- PORT=3000
- TURBO_TOKEN=super-secret-turbo-bearer-token
- STORAGE_PROVIDER=s3
- STORAGE_PATH_S3=my-monorepo-turbo-cache
- AWS_REGION=us-east-1
- AWS_ACCESS_KEY_ID=${AWS_ACCESS_KEY_ID}
- AWS_SECRET_ACCESS_KEY=${AWS_SECRET_ACCESS_KEY}
ports:
- "3000:3000"
EOF{
"$schema": "https://turbo.build/schema.json",
"tasks": {
"build": {
"dependsOn": ["^build"],
"outputs": [
"dist/**",
".next/**",
"!.next/cache/**",
"build/**"
],
"cache": true
},
"lint": {
"cache": true
},
"test": {
"dependsOn": ["build"],
"outputs": ["coverage/**"],
"cache": true
}
}
}Always exclude volatile or process-dependent cache paths like `!.next/cache/**` from `turbo.json` outputs to avoid inflating S3 tarball sizes and causing signature mismatches.
Do not hardcode `TURBO_TOKEN` or AWS credentials into `turbo.json`. Turborepo automatically reads remote cache credentials from the environment variables `TURBO_API` and `TURBO_TOKEN`.
Agent Execution & Trigger Invocation
Activate the skill using natural language triggers to configure runtime and CI remote cache links.
Invoke the skill by entering one of its pre-registered trigger phrases. The agent will read the procedural execution rules from `SKILL.md` and generate deterministic environment files and CI scripts without hallucinating proprietary Vercel CLI login commands.
echo 'TURBO_API="http://localhost:3000"\nTURBO_TOKEN="super-secret-turbo-bearer-token"' > .env.turboname: CI Pipeline
on: [push, pull_request]
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: pnpm/action-setup@v3
with:
version: 8
- uses: actions/setup-node@v4
with:
node-version: 20
cache: 'pnpm'
- run: pnpm install --frozen-lockfile
- name: Run Build with Turborepo S3 Remote Cache
env:
TURBO_API: ${{ secrets.TURBO_REMOTE_CACHE_URL }}
TURBO_TOKEN: ${{ secrets.TURBO_REMOTE_CACHE_TOKEN }}
TURBO_TEAM: "monorepo-team"
run: pnpm exec turbo run build test --summarizeUse `turbo run <task> --summarize` to generate `.turbo/runs/*.json`. This allows the agent to parse cache hit/miss statuses deterministically without scraping raw terminal output.
When using self-hosted remote caches, `TURBO_TEAM` must be populated (any non-empty slug works) because Turborepo formats artifact URLs as `/v8/artifacts/:hash?teamId=:team`.
Verification, Cache Validation & Output Quality Gate
Verify remote cache uploads and downloads through sequential runs ensuring return code 0 and FULL TURBO.
A complete remote cache implementation must be verified with a two-pass build: an initial pass that populates the S3 backend, and a second pass (after cleaning local build artifacts) that produces instant remote cache hits across all workspaces.
turbo run build --api="http://localhost:3000" --token="super-secret-turbo-bearer-token" --team="monorepo-team" && git clean -xdf packages/*/dist apps/*/.next && turbo run build --api="http://localhost:3000" --token="super-secret-turbo-bearer-token" --team="monorepo-team"#!/usr/bin/env bash
set -euo pipefail
echo "==> Cleaning local build artifacts..."
rm -rf .turbo apps/**/dist apps/**/.next packages/**/dist
echo "==> Running build pass (Remote Fetch Expected)..."
OUTPUT=$(npx turbo run build --summarize)
if echo "$OUTPUT" | grep -q ">>> FULL TURBO"; then
echo "[SUCCESS] Remote caching with S3 verified. Full turbo hit!"
exit 0
else
echo "[WARN] Local or remote cache missed. Check S3 bucket connectivity."
exit 1
fiRun verification with `TURBO_LOG_ORDER=grouped` and `TURBO_REMOTE_ONLY=true` during debugging to strictly verify that dependencies are served from S3 rather than local machine disks.
Running `rm -rf node_modules` during cache validation will cause false negatives if package lockfiles or resolved binaries change hash fingerprints between runs.
Real-World Scenario: Scaffold Self-Hosted MinIO Turborepo Remote Cache for Monorepo CI
“Setup turborepo remote cache s3 using our self-hosted MinIO instance at https://minio.internal.net. Update turbo.json outputs for our Next.js web app and internal TypeScript packages, and configure our GitHub Actions workflow to slash CI build time turbo.”
Runtime Troubleshooting & Failure Modes
Root Cause: The remote cache server rejected the request due to an invalid or missing Bearer token in TURBO_TOKEN, or the AWS IAM user lacks s3:PutObject / s3:GetObject permissions on the designated S3 bucket.
# Verify remote cache server authorization header and S3 bucket IAM policy
curl -v -H "Authorization: Bearer super-secret-turbo-bearer-token" \
"http://localhost:3000/v8/artifacts/status?teamId=monorepo-team"
# Ensure TURBO_TOKEN in your environment or GitHub Secrets matches TURBO_TOKEN in ducktors/turborepo-remote-cacheRoot Cause: The glob patterns in turbo.json 'outputs' array do not match the actual artifact locations produced by the package build script (e.g., framework outputs to '.next' or 'build' instead of 'dist').
// In turbo.json under tasks.build, explicitly match all possible build outputs:
{
"tasks": {
"build": {
"outputs": ["dist/**", ".next/**", "!.next/cache/**", "build/**", "out/**"]
}
}
}Frequently Asked Questions (Turborepo Remote Caching with Self-Hosted S3 / MinIO SOP)
Q:Can I use Turborepo Remote Caching with Self-Hosted S3 / MinIO across Codex, Claude Code, and Cursor simultaneously?
Yes. The skill conforms to the universal SKILL.md specification. Once installed in `.cursor/skills/` or mounted in the Claude Code runtime environment, all agents follow the identical procedural rules, ensuring team-wide consistency across IDEs and automated terminals.
Q:How does Turborepo Remote Caching with Self-Hosted S3 / MinIO prevent context window overflow during long agent sessions?
Instead of forcing the LLM to inspect huge raw build logs and guess compile errors, the skill directs the agent to execute `turbo run <task> --summarize`. The agent parses concise JSON execution summaries, minimizing token consumption while diagnosing build or cache misses.
Q:Does this skill require escalated root or container permissions?
No. The skill is audited with a security score of 98/100. It requires standard workspace filesystem permissions (`fs_write: workspace`) and executes purely through unprivileged npm/pnpm/yarn package manager commands without root container execution.
Ready to equip your autonomous agent with Turborepo Remote Caching with Self-Hosted S3 / MinIO?
Copy the complete audited SKILL.md specification or download the 1-click zip bundle directly from our verified registry.