Whitelabel
Public surface

Public Content System

Publish SSR-friendly guides and landing pages without coupling them to the authenticated app shell.

Public Content System

Keep the public surface simple and indexable.

In this starter

  • Markdown pages are registered in one content catalog: guides under /guides, and standalone pages such as /about, /contact, /privacy and /developers at the root.
  • Every page is served as HTML and as Markdown, and the registry also produces the sitemap, llms.txt, the route policy and the links in the footer, so a page added once is discoverable everywhere.
  • A page may quote facts about the deployment through tokens (the project name, the publisher, the sandbox origin, the MCP tools), listed in scripts/lib/content-tokens.ts and resolved when the content modules are generated.
  • The server renders those pages for sharing, SEO, and fast first paint.

Why split public content from the app shell?

  • Marketing and docs can evolve without dragging app state into every route.
  • The authenticated app can change faster than the public website.
  • It keeps the codebase honest about what must work without login.

What to replace

  • The example guide pages with your own acquisition, help, onboarding, or product education content.
  • The about, contact and privacy pages with what is true of your product. Keep the paths: they are the ones people and agents probe before trusting a site.
  • The developers page only where your API differs; its tables are built from the deployment and stay correct on their own.

Related pages

Local-First WorkspaceStart with on-device drafts and optional sync so the product remains useful before backend complexity arrives.Deployment PrerequisitesCreate Cloudflare resources, secrets, and domains in the right order before the first deploy.Customization ChecklistTrack the project-specific values you must replace before calling the starter production-ready.