CMS Overview - Hiveku Builder

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.

File-based, not database-backed

Every entry is a real file in your repo — .mdx for long-form, .json for structured data

Manifest-driven schema

A single hiveku.cms.json declares every collection, field, and route

Edited in the site builder

The CMS icon above the preview opens your collections, a form editor, and version history

AI-native

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 version snapshot, the same history that tracks every other file in your project. 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 built-in file history, 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 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 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:

---
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:

{
  "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 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 for examples.

Where the CMS Lives in the Site Builder

Open your site in the site builder and click the CMS icon in the row of icons above the preview. (The folder icon beside it, Show File Tree, opens the files for direct editing.) For a walkthrough with screenshots, see Edit Your Content in the CMS. In the CMS you’ll see:

A collections rail on the left, with entry counts and an Assets media library
An entries table with search, status filters (Draft / Published / Scheduled / Archived), configurable columns, and pagination
An entry editor for the selected entry, generated from the manifest’s field definitions, with autosaving drafts
An Entry details sidebar — the status pill, publish and schedule actions, deploy state, and version history
A bulk import modal for CSV or JSON imports
Manage collections for editing the manifest itself, including one-click collection presets

See Editing Content in the CMS Panel for a full walkthrough.

A Minimal Example

A two-collection site — blog posts that reference an author — fits in one manifest:

{
  "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", "referenceCollection": "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)

Use the CMS
Use a regular page instead

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

What’s Next?

Set Up the CMS on Your Site

First-time setup — scaffold the manifest and a default collection

Migrate an Existing Site

Move hardcoded content into the CMS so non-developers can edit it

The Manifest

Full reference for hiveku.cms.json

Field Types

Every supported field type and how it appears in the editor

File-based, not database-backed

Manifest-driven schema

Edited in the site builder

AI-native

​Why File-Based?

​Key Concepts

​Manifest

​Collection

​Entry

​Field

​Reference

​Where the CMS Lives in the Site Builder

​A Minimal Example

​When to Use the CMS (and When Not To)

​What’s Next?

Set Up the CMS on Your Site

Migrate an Existing Site

The Manifest

Field Types

Why File-Based?

Key Concepts

Manifest

Collection

Entry

Field

Reference

Where the CMS Lives in the Site Builder

A Minimal Example

When to Use the CMS (and When Not To)

What’s Next?