Architecture
How Kernset is built
If you are evaluating a CMS for your agency stack, this is the page that tells you what you would be committing to. The actual stack, the trade-offs, and the parts that matter for your client portfolio.
- Next.js 16
- React 19
- TypeScript 5
- Static, cached, or Node
- EU-hosted
How it works
Three steps from schema to published page
-
Define blocks in TypeScript
Write each page's block schema next to your source code. Fields, validations, and editor helper text live in your repo - not in a database config.
-
Run sync once to register structure
One CLI command reads your schemas and creates the matching content slots. It never touches existing content. Re-run any time.
-
Client edits content, you publish
The client edits the typed fields you exposed. When they publish, the client website updates within seconds - via direct fetch, a cache refresh, or a webhook to your own Node app.
Block model
Pages are typed blocks. The schema lives in your code.
Each page is a document with an array of typed blocks. Each block declares its fields, validations, and helper text in TypeScript. Two interaction modes: fixed blocks (positional, defined by code, content-only edits) and flexible zones (a designated region where the client can add and reorder blocks from an allowlist you choose). Block schemas live in your code, not a JSON config in the database.
// Declare the blocks Kernset should manage on this page.
// Static literal array - parsed via AST at sync time.
export const cmsBlocks = [
'hero',
'featureList',
'testimonial',
'flexibleZone:content_zone',
'cta',
] as constThree deployment shapes
Same content, three places it can run
The CMS itself runs on your own EU server. The client website runs wherever fits the client.
-
Direct publish (always live)
Plain HTML, CSS, and JavaScript on any shared host. No Node required. The site fetches content live from the public content API.
-
Cached site (refreshes within seconds)
An edge platform like Vercel with on-demand cache refresh. When the editor publishes, the cache updates within seconds.
-
Your own Node application
Self-hosted Node app on your own VPS. The same publish flow signals the cache; the receiver decides what to invalidate.
Safe publishing
Your client's content is never overwritten
When you change pages in code, run the sync command. The structure updates, the editor's content stays put.
$ pnpm content-sdk sync
ok home (rule 2: structure unchanged)
ok services (rule 3: appended featureList)
warn legacy-page (rule 4: orphaned route - content preserved)
ok blog/index (rule 1: page created as draft)
Sync complete. 0 errors, 1 warning.Operations
What runs underneath
-
Versioning and drafts
Every page is versioned with configurable retention (25 versions per page by default). Drafts are first-class. Editors stage, preview, and either publish or discard.
-
Public content API
A read-only surface, separate from the admin. The client site is resolved by URL path, never by request body. Draft content is gated by signed preview tokens.
-
Signed live preview
The admin renders the client site inside a preview frame with signed URLs scoped to the editor's session. Draft data never leaks outside that session.
-
Isolation between client websites
Every record carries the website it belongs to. Database constraints prevent cross-website references. The picker filters in the admin only show the active website's records.
-
Encrypted nightly backups
Encrypted database backups every night with rotatable keys, kept in EU. Restore is a single command.
-
Structured logs and error tracking
JSON-structured logs and optional error-tracking integration with PII scrubbing. Easy to ship to whatever observability stack you already use.
-
EU hosting and EU jurisdiction
Servers and operating company are both in the EU. Data never leaves the EU unless the client explicitly opts in to a non-EU module.
-
Scheduled jobs run in-process
Preview cleanup, audit purges, and other periodic work run inside the CMS. No separate worker service to operate at V1 scale.
Modules and out-of-scope
What Kernset will and will not do
The honest list. Yes, no, and never.
Is there a chatbot module?
Yes, optional. Retrieval over per-website knowledge documents you upload. Sellable to your client as a per-website add-on, gated per client website.
Is there an AI assistant for editors?
Yes, optional. Inline translate, content suggestions, SEO assists. Strict opt-in per organisation; turning it off removes the surface entirely.
Is there premium analytics?
Yes, optional. Cookieless, GDPR-aligned per-website dashboards with real-time visitor traffic and exportable reports. Sellable to your client as a per-website add-on.
Is there a visual page builder?
No, and never will be. Layout and design live in your code. Clients edit only the typed fields you exposed. This is the single most load-bearing decision in Kernset.
Can clients add their own block types?
No. New block types come from your code. Clients can add and reorder blocks inside a flexible zone, but only from an allowlist you defined.
Will Kernset host my client's Next.js app?
No. The CMS runs on our EU VPS. The client website runs wherever you decide: shared hosting, edge platform, or your own Node app.
Want to evaluate Kernset against your stack?
Send a message. We will walk through the editor, the publish flow, and the parts of the architecture that matter for your client portfolio.