Skip to main content
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 /v3

The right pane in the editor has a CMS mode with collection picker, form editor, and live preview

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 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 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 /v3

Open the /v3 editor 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 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", "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

​
What’s Next?

Initialize Your CMS

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