Fumadocs

Key features

• MDX content source Fumadocs MDX is the default content source, with adapters for external CMS products and realtime content updates, so authors write Markdown or MDX while the framework builds the page tree and navigation.[1]

• Multi-provider search Document search ships built in with a choice of providers including Orama and Algolia, alongside fetch-based options, so teams pick the index that fits their scale rather than wiring search themselves.[1][2]

• OpenAPI reference generation API definitions generate interactive OpenAPI reference pages inside the same docs site, keeping endpoint documentation next to guides instead of on a separate portal.[1]

• TypeScript Twoslash samples Code samples support TypeScript Twoslash annotations, so docs pages show type-checked, hoverable snippets that stay honest about the APIs they demonstrate.[1]

• Five-framework support One scaffolding command starts projects on Next.js, Astro, Waku, React Router, or TanStack Start with Node 22 or newer, so teams keep their existing React stack.[1]

• Static output with RSC and i18n Sites render through React Server Components with static generation and internationalization support, producing fast pages that can be served as fully static files.[1][2]

• Component CLI The command-line tool installs and forks theme components Shadcn-style, so customization means owning real component code rather than overriding theme settings.[1][2]

• LLM-ready output New apps configure llms.txt generation and MCP support by default, so AI assistants and agents can read the published documentation as structured context.[1]

Who will love it

• React teams building product documentation with full code control will love it, because the breakable-framework philosophy trades abstraction for direct ownership of every docs component.[1][2]

• Developers customizing docs beyond what config-file frameworks allow will love it, because the composable UI and CLI forking path exist precisely for layouts that settings cannot express.[1][2]

• Projects adding a blog, FAQ, or showcase beside their docs will love it, because documentation plus blog use cases are documented first-class patterns rather than bolt-on themes.[1][2]

Who should avoid it

• Teams without React developers should avoid it, because the official comparison states builders may need more React knowledge than with opinionated alternatives such as Docusaurus.[1]

• Teams wanting a provider-hosted docs service should avoid it, because every deployment path runs on infrastructure the adopter provisions: framework hosting, Docker, or static files.[1]

• Teams expecting a vendor-supported edition with SLAs should avoid it, because the MIT-licensed framework has no paid tier and maintenance funding runs through voluntary sponsorship.[1][2]

Compatibility and alternatives