Project Structure

Every CamelMind project follows the same directory structure. Most of your work will happen in just a few folders, while the rest powers the framework behind the scenes.

This guide explains what each folder is for and when you'll need to edit it.

my-docs/
├── app/                      # Next.js routes and rendering
├── components/               # UI and MDX components
├── content/                  # Documentation pages
├── lib/                      # Internal utilities
├── nav/
│   └── nav.yml               # Sidebar navigation
├── public/                   # Images and downloads
├── scripts/                  # Build utilities
├── camelmind.config.ts       # Site configuration
├── versions.yml              # Documentation versions
├── next.config.ts            # Next.js configuration
├── .env.example              # Configuration template; duplicate to .env.local before running
├── package.json
└── tsconfig.json

The content/ folder

Every documentation page is an MDX file stored under content/. Every page is a .mdx file — Markdown with optional JSX components — with YAML frontmatter at the top for title and description.

content/
├── getting-started/
│   └── overview.mdx
├── guides/
│   └── writing-docs.mdx
└── reference/
    └── configuration.mdx

Unlike many documentation frameworks, CamelMind does not derive URLs from your folder structure. URLs are defined in nav.yml, giving you complete control over your site's navigation.

The nav/nav.yml file

nav.yml is the single source of truth for what appears in the sidebar and which URL each page is served at. Every entry maps a slug (the public URL) to a file (the MDX source):

nav:
  - label: "Getting Started"
    dropdown: false
    noDropdown: true
    items:
      - label: "Project Structure"
        slug: /getting-started/project-structure
        file: content/getting-started/project-structure.mdx
        roles: []

A page in content/ that isn't registered here won't be reachable — and a page can be registered at multiple slugs with different labels or roles. See Navigation and the Nav Schema reference for every field.

The versions.yml file

versions.yml defines the documentation versions your site publishes, such as latest, v1, or v2.

versions:
  - id: "latest"
    label: "Latest"
    stable: true
    nav: nav/nav.yml

A fresh scaffold ships with a single latest version. Add entries here when you're ready to publish multiple versions side by side — see Versioning.

The camelmind.config.ts configuration file

The root config file for site-wide behavior such as title, tagline, auth settings, GitHub link, API reference, and llms.txt output.

const config: CamelMindConfig = {
  title: "My Docs",
  tagline: "Documentation made simple.",
  url: process.env.CAMELMIND_URL ?? "http://localhost:3000",

  contentDir: "content",
  navFile: "nav/nav.yml",
  versionsFile: "versions.yml",

  auth: { enabled: false, requireLogin: false, provider: "dev-mock", /* ... */ },
  links: { github: "https://github.com/you/your-repo" },
  ai: { llmsTxt: { enabled: false, directive: "" } },
}

Most secrets and environment-specific values (auth toggles, the site URL) are read from environment variables defined in .env.example / .env.local, rather than hardcoded here. See the Configuration Reference for every field.

The app/ folder

The app directory contains the Next.js application that powers your documentation site.

The components/ folder

React components split into two groups:

• Site chrome — Nav/, Sidebar/, Toc/, Breadcrumbs/, PageNav/, Search/, SectionCards/, ApiReference/, and similar folders render the surrounding site UI (top nav, sidebar, table of contents, search modal, and so on).
• components/mdx/ — the components available directly inside your .mdx content: Callout, Steps, Tabs, Details, Icon, LLMOnly, and LLMIgnore.

See MDX Components for how to use each one in your content.

The lib/ folder

The engine room: plain TypeScript modules that load and resolve content, with no JSX. You generally won't need to edit these, but they're the layer to look at if you're extending CamelMind's behavior.

The scripts/ folder

Standalone automation tooling for producing specialized release artifacts outside of the normal web deployment pipeline:

See Offline Export for how these fit into a release workflow.

Root config files

Next steps