Choose a static or server deployment for your docs

A documentation site is a strong candidate for static hosting, but “the pages are mostly Markdown” is not enough to make the decision. Choose the deployment model from the request-time behavior you need after the build has finished.

Ginko Docs supports both models. The important distinction is not visual: generated and server-rendered sites use the same routes, navigation, search interface, and content components. The distinction is which responses require a running Nitro server.

What a static build keeps

A generated site includes the parts readers use most often:

• prerendered docs, blog, and landing pages;
• Nuxt payloads for client-side navigation;
• the MiniSearch data used by the command center;
• /raw/**.md copies of public pages;
• llms.txt and llms-full.txt catalogs;
• sitemap, robots, and generated PNG social cards.

Browser features still run after deployment. Search, image zoom, the language switcher, banner dismissal, Plausible analytics, and the feedback interface do not require a Node server.

This makes static output a good default for public documentation whose content changes through a build and deploy.

What a Nitro server adds

Some capabilities depend on the incoming HTTP request. A Nitro deployment can inspect an Accept: text/markdown header and return Markdown from the normal page URL. It can also emit response link headers and serve the read-only MCP endpoint at /mcp.

A file host cannot reproduce those behaviors from the generated directory alone. It can serve the explicit raw files and LLM catalogs, but it cannot negotiate a different representation for one URL or execute MCP tools.

Use a server deployment when those request-time interfaces are part of the product rather than optional conveniences.

Make the choice explicit

Do not advertise /mcp on a site that only deploys static files. The page action settings can hide that menu entry, but they do not change which routes the build creates.

The deployment guide lists the commands and output checks for both targets. Test the deployed artifact rather than assuming that a successful development server proves the chosen hosting behavior.