How GitBook serves 30,000 sites with sub-second content updates
Source: Vercel Blog
Overview
GitBook hosts 30,000 documentation sites on a single Vercel deployment, serving 120 million page views each month. Companies such as n8n, Nvidia, and Zoom rely on the platform to keep their docs fast and up‑to‑date. For modern engineering teams and coding agents, documentation is as critical as the production code it describes, and GitBook sits at the center of that expectation.
Publishing Model and Challenges
GitBook’s publishing workflow mirrors software development: propose changes, review, and merge. With 30,000 independently managed sites, each on its own update cadence, keeping content both fast and fresh presented a complex engineering problem.
Before migrating to Vercel, editors would merge changes, visit the published site to validate, and often see an outdated version of the content. As Steven Hall, Head of Engineering at GitBook, recalls:
“One of our customers planned a large feature release, and on launch day, the docs lagged behind the rest of the product. That was the moment we really internalized that docs are as important as your code going to production.”
Solution on Vercel
The published content frontend runs on Next.js and is open source. When Vercel introduced the use cache directive, the team saw a way to cache individual data‑fetching functions rather than full page responses. This approach:
- Deduplicates expensive API calls across requests.
- Makes cache behavior visible directly in code instead of hidden in external configuration.
Tag‑Based Invalidation
Invalidation in a multi‑tenant system is tricky—broad cache purges are wasteful. A typo fix in one site should not trigger revalidation for the remaining 29,999 sites.
GitBook already had a reliable signal for stale content: a merge event (via GitBook’s app, GitHub, or GitLab). The team built a tag‑based invalidation system triggered by those events:
- Cached data is tagged by the content unit it represents.
- When a merge occurs, only the affected tags are revalidated.
- All other cached data remains untouched.
As a result, a change becomes globally visible within ~300 ms. GitBook processes ≈ 40,000 invalidations daily.
“Outside of building our own caching, I don’t think we considered anything else,” says Hall.
Impact of AI‑Driven Traffic
AI‑driven traffic to GitBook documentation surged 5× year‑over‑year in 2025 and now accounts for 41 % of all page views. Large language models (LLMs) and automated systems crawl docs programmatically, using GitBook as a source of truth for internal tooling, SDKs, and AI applications.
This shift changes the infrastructure math:
- Human readers typically visit a handful of pages per site.
- AI crawlers can sweep every page across hundreds of sites in a single session, hitting cold‑cache paths that humans rarely touch.
- Multiplying this behavior across 30,000 sites demands a caching foundation that handles high volume and unpredictable traffic while maintaining immediate consistency after every change.
Hall notes that the caching architecture wasn’t chosen specifically for AI traffic, but it proved to be the right foundation:
“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.”
Future Outlook
The caching infrastructure continues to evolve. Upcoming features such as adaptive documentation—which tailors content based on the reader—will add complexity to multi‑tenant caching. As AI traffic keeps climbing, request volume across the 30,000 sites will only grow.
“Volume is going up everywhere. 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,” Hall says.
About GitBook
GitBook is an intelligent documentation platform used by more than 30,000 teams to create, publish, and maintain product and developer documentation at scale. Its published content frontend is open‑source and runs on Next.js.