Norcube CMS

Norcube CMS is a visual editor for content that lives in your git repo as Markdown / YAML / JSON files. Authors get a structured UI scoped to a schema you declare in .norcube/cms/config.yml; every Publish becomes a commit on the branch the site is connected to. Your build pipeline reads the same files it always did — Astro import, Hugo resources.Get, SvelteKit page data — and ships the result through your existing host.

There is no separate content database. The CMS holds the connection (org → site → installation → repo → branch), mints short-lived installation tokens, and proxies reads / writes against GitHub. The content is yours, in your repo, in your VCS.

What you can do

Get started

Wire a fresh repo through to your first published page in ~10 minutes.

Schema reference

Every field type, every config.yml knob, with the YAML it produces.

Media library

Named storages with picker scoping, upload validation, inline-SVG mode, dedup.

AI Assistant

A per-page chat copilot that proposes structured edits you approve on a card.

AI schema generation

Scaffold a working .norcube/cms/ from a repo scan, full or single-block.

Collaboration

Per-page discussion threads + the site-wide activity feed.

Version history

Per-page commit feed with schema-aware diff and three flavours of rollback.

Core concepts in one minute

Site — one connection from your org to a (GitHub installation, repo, branch) triple. An org can host any number of sites.
Schema — your content shape, declared in .norcube/cms/config.yml plus per-block files under .norcube/cms/collections/ and .norcube/cms/blocks/. The editor renders fields strictly to this schema; values outside it are flagged (see extraKeysPolicy).
Collection — a directory of content files (one collection per page type: blog posts, case studies, marketing pages). Files are Markdown with YAML frontmatter; the body renders as rich text, the frontmatter renders as the structured fields the schema describes.
Storage — a named pointer to where media bytes live (src/assets/icons, public/uploads, eventually R2 / S3 / GCS). Fields opt in via storage:. See Media library.
Sidecar — the CMS stamps each block / item with a UUID _id so identity survives reorders. The IDs live in .norcube/cms/meta/<page>.yml (sidecar file) rather than your content YAML — your build pipeline never sees them.

How it fits with your stack

The CMS doesn't care which static-site generator (or framework) reads the content. Anything that can parse YAML frontmatter + Markdown works:

Astro — import SVGs out of src/assets/, query Astro.glob over a collection directory.
SvelteKit — +page.server.ts reads the matching .md for the route.
Hugo / Eleventy / Jekyll / Zola — their built-in front-matter loaders understand the shape already.
Next.js (Pages or App) — contentlayer, gray-matter, or a custom loader.

You write the integration once and forget the CMS exists at build time. The editor never inserts framework-specific code into your content.