Docs as production: How GitBook revalidates 30,000 sites in milliseconds
GitBook runs 30,000 documentation sites on a single Vercel deployment, serving 120 million page views monthly. Customers including n8n, Nvidia, and Zoom rely on the platform to keep API references and product guides current. With 41% of traffic now coming from AI crawlers and automated systems, the caching layer has become as critical as the content itself.
GitBook's publishing workflow mirrors software delivery: propose changes, review, then merge. Each of the 30,000 sites operates on its own update schedule, which made keeping content both fast and fresh a genuinely hard problem. Before the Vercel migration, editors would merge a change, visit the live site to validate, and see the old version. "One of our customers planned a large feature release, and on launch day, the docs lagged behind the rest of the product," says Steven Hall, Head of Engineering at GitBook. "That was the moment we really internalized that docs are as important as your code going to production."
Tag-based invalidation replaces broad purges
The published content frontend runs on Next.js and is open source. When Vercel introduced the use cache directive, GitBook adopted it for individual data-fetching functions rather than full page responses. Expensive API calls are deduplicated across requests, and cache behavior lives in code instead of external configuration.
Invalidation posed the larger challenge. In a multi-tenant system, purging the whole cache is wasteful: a typo fix on one site should not trigger revalidation for the other 29,999. GitBook already had a reliable staleness signal in merge events from its own app, GitHub, or GitLab. The team built tag-based invalidation around those events—cached data is tagged by content unit, and only affected tags revalidate when a merge lands.
Today, merged content becomes globally visible in under 300 milliseconds. GitBook processes 40,000 invalidations daily. "Outside of building our own caching, I don't think we considered anything else," says Hall.
"We considered building a caching layer ourselves, but Vercel was really the only option that made sense for our multi-tenant architecture."
Steven Hall, Head of Engineering @ GitBook
Serving traffic that no longer behaves like readers
AI-driven requests to GitBook documentation grew 5x year-over-year in 2025 and now make up 41% of all page views. LLMs and automated agents crawl docs programmatically, treating GitBook as a source of truth for SDKs and internal tooling.
That shifts the infrastructure calculus. A human typically visits a handful of pages on one site; an AI crawler may sweep every page across hundreds of sites in a single session, hitting cold cache paths no human would touch. Across 30,000 sites, the caching foundation must absorb not just more traffic but fundamentally less predictable traffic—while keeping latency consistent after every content change and infrastructure costs bounded.
Hall notes the caching architecture wasn't chosen with AI in mind, but it proved to be the right foundation anyway. "We need fast docs regardless of whether AI or humans are reading them. Our target is closer to 100% cache hits. Cache hits mean fast docs, and fast docs are a critical feature of GitBook."
Keeping latency predictable as volume climbs
The caching work continues. Adaptive documentation—content that changes based on the reader—makes multi-tenant caching considerably more complex. And with AI traffic rising, request volume across the platform will keep growing.
"Volume is going up everywhere," Hall says. "Engineers shipping more means more docs changes. LLMs are crawling more pages every day. Our main goal is to maintain that high bar for latency and predictability as we scale."
