Current
Production Docs Content Injection
Limits that shape how published docs pages, code blocks, search, and AI-friendly routes render on shared infrastructure
Production Docs Content Injection
Status: Describes the implemented state
How published docs reach the renderer
When you publish a branch, Doxa stores that published version of your docs. The shared docs renderer, the same code that serves every <slug>.doxa.page site and custom domain, reads that version and produces each page a reader opens.
Sites that have saved output are served from it. For other requests, a live renderer produces the page. Every renderer call receives the content of one site, so each site shows only its own pages, navigation, theme, icons, and search results, even though many sites share the same renderer process.
Because that process is shared, Doxa limits how much work one site can use. The limits below apply to every site.
Limits for published sites
| Limit | Value | What readers see above the limit |
|---|---|---|
| CPU per renderer call | 5 seconds | The call fails. A request that can be served safely falls back to the shared renderer. |
| Page MDX at render | 512 KB (UTF-8) | A short "page too large" notice in place of the page body. |
| Code block size | 32 KB of characters | The block is drawn as plain text without syntax colors. |
| Highlighted code per page | 128 KB of characters | Later code blocks on the page are drawn as plain text. |
| Line length in code | 2,000 characters | That line is drawn without syntax colors. |
| Search index | One site keeps at most 5 MB of its index in cache. An index above 8 MB is not read. | Search returns no results for that site. |
/llms-full.txt | 5 MB | The file stops adding pages at the budget and ends with a note that /llms.txt lists every page. |
/llms.txt | 2 MB of page bodies read for descriptions | Later pages are listed by navigation title only, without a description. |
The shared search cache holds 20 MB of serialized indexes across all sites. When it is full, the least recently used indexes are removed first.
Plan your content around the limits
Split long pages. Keep each page under 512 KB. Move long reference material into several pages linked from a navigation group.
Keep code blocks short. Keep each block under 32 KB. For generated or minified files, show an excerpt and link to the full file instead.
Limit highlighted code per page. A page with many large code blocks loses highlighting after 128 KB of code. Split such pages by topic.
Wrap long lines. Lines over 2,000 characters are drawn without colors.
Keep the search corpus focused. A site with a very large amount of content can exceed the search index limit. Split large sections into separate pages, and remove pages that no longer belong.
Note:
These limits apply when a page is rendered. They do not change your saved content, and the fallbacks are what readers see on the live site. Check long pages on the live site after you publish.
When a renderer call falls back
If a renderer call is missing the inputs it needs, it fails closed and Doxa serves the page from the shared renderer. Readers still get the page. If you see an unexpected plain-text or unstyled page after a publish, republish the branch and check the page again.
Related guides
How the live renderer and dispatcher modes serve published sites.
Saved HTML and route data created when a site is published.
How published pages are cached and invalidated.
The Markdown style Doxa uses for page MDX.