> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hiveku.com/llms.txt
> Use this file to discover all available pages before exploring further.
# CMS Overview
> Hiveku Builder's file-based CMS — what it is, why it's file-based, and how it fits into your project
The Hiveku CMS is a lightweight, file-based content management system built into every project. It gives non-technical teammates a Webflow-style editing experience for the structured content on your site — blog posts, products, testimonials, FAQs, team members — without giving up the version control and AI-friendliness that come from keeping content in code.
Every entry is a real file in your repo — `.mdx` for long-form, `.json` for structured data
A single `hiveku.cms.json` declares every collection, field, and route
The right pane in the editor has a CMS mode with collection picker, form editor, and live preview
The AI can scaffold collections, write entries, and refactor your components to read from the CMS
## Why File-Based?
Most CMSes store content in a database and serve it through an admin panel. That works, but it adds infrastructure, latency, and a moving piece that's hard to version. Hiveku's CMS keeps every entry as a file in your project repo, which means:
* **Version controlled by default** — every edit becomes a normal commit-style snapshot in `builder_code_versions`. Roll back any entry to any point in its history.
* **Reviewable in pull requests** — content changes show up as diffs, not opaque database writes.
* **No DB roundtrips at runtime** — your site reads the files directly at build time (or at request time for SSR), so there's no extra service to provision, monitor, or pay for.
* **AI agents can read and write it** — content lives next to code, so the AI can refactor a hardcoded React component to pull from the CMS in a single step.
* **Portable** — clone your project, get all the content with it. Export a project, the CMS comes along.
Versioning is handled by the platform's `builder_code_versions` table, the same system that tracks every other file in your project. You don't need to wire up Git or any other history system.
## Key Concepts
### Manifest
A single file at the project root: `hiveku.cms.json`. It declares every collection your site has, the fields each entry must have, where the entries live on disk, and the URL pattern they map to.
See the [manifest reference](/cms/manifest) for the full schema.
### Collection
A group of entries that share the same shape — for example, "Blog Posts", "Products", or "Team Members". Each collection has:
* An `id` (used in references and tooling)
* A `path` on disk (`content/blog`, `content/products`, etc.)
* A `format` — either `mdx` (frontmatter + body, good for long-form) or `json` (structured data only)
* A `fields` array describing every field on each entry
* An optional `routePattern` describing the URL each entry maps to
See [Collections](/cms/collections) for naming conventions, format choice, and reusable patterns.
### Entry
One file inside a collection's directory. For an MDX collection at `content/blog/`, an entry looks like:
```mdx theme={null}
---
title: "Welcome to the Blog"
publishedAt: "2026-04-01"
status: "published"
tags: ["news", "launch"]
---
Welcome to our new blog. We're excited to share...
```
For a JSON collection like `content/testimonials/`, it looks like:
```json theme={null}
{
"name": "Jane Doe",
"company": "Acme",
"quote": "Hiveku saved us weeks of work.",
"image": "/uploads/jane.jpg"
}
```
### Field
A typed slot on an entry — `title`, `publishedAt`, `image`, `tags`. The CMS form editor is generated from your fields, so giving a field a sensible `type` and `name` is enough to get the right UI control automatically.
See [Field Types](/cms/field-types) for the full list of supported types.
### Reference
A field that points at another entry in another collection — for example, a `blog` post's `author` field that points at an entry in the `authors` collection. References show up as picker fields in the form editor and let you reuse data across collections.
See [Linking Collections with References](/how-tos/cms-references) for examples.
## Where the CMS Lives in /v3
Open the [/v3 editor](/v3/editor/overview) and look at the right pane — it has three modes you can switch between:
* **Preview** — your live site preview
* **Code** — direct file editing
* **CMS** — the content editor
In CMS mode you'll see:
1. A **collection picker** at the top (Blog Posts, Products, etc.)
2. A scrollable **entry list** with search, filter, and pagination
3. A **form editor** for the selected entry, generated from the manifest's field definitions
4. A **version history** drawer for rolling back any entry
5. A **bulk import** modal for CSV or JSON imports
6. A **collection manager** (gear icon) for editing the manifest itself
See [Editing Content in the CMS Panel](/cms/editing-content) for a full walkthrough.
## A Minimal Example
A two-collection site — blog posts that reference an author — fits in one manifest:
```json theme={null}
{
"version": 1,
"collections": [
{
"id": "authors",
"name": "Authors",
"path": "content/authors",
"format": "json",
"slugFrom": "filename",
"fields": [
{ "name": "name", "type": "string", "required": true },
{ "name": "bio", "type": "markdown" },
{ "name": "avatar", "type": "image" }
]
},
{
"id": "blog",
"name": "Blog Posts",
"path": "content/blog",
"format": "mdx",
"slugFrom": "filename",
"fields": [
{ "name": "title", "type": "string", "required": true },
{ "name": "publishedAt", "type": "date" },
{ "name": "author", "type": "reference", "collection": "authors" },
{ "name": "tags", "type": "array", "items": "string" },
{ "name": "body", "type": "markdown", "isBody": true }
],
"routePattern": "/blog/{slug}",
"defaultSort": "publishedAt desc"
}
],
"webhooks": []
}
```
That's enough for the CMS panel to render two collections, generate a form for each, wire up the author picker, and produce one URL per blog post.
## When to Use the CMS (and When Not To)
* Repeating content of the same shape — blog posts, products, team members, testimonials, case studies, FAQs, events, locations
* Content that non-developers need to edit
* Content you want to query or sort programmatically (latest 5 blog posts, products in a category)
* Anything you might want to migrate to a different rendering later — the data stays portable
* One-off pages — Home, About, Pricing, Contact
* Pages with bespoke layouts that don't share a template with anything else
* Marketing pages where the layout *is* the content
See [Manage Website Pages](/how-tos/manage-pages) for the page tree, which is separate from CMS collections.
## What's Next?
First-time setup — scaffold the manifest and a default collection
Move hardcoded content into the CMS so non-developers can edit it
Full reference for `hiveku.cms.json`
Every supported field type and how it appears in the editor