Model it in barakoCMS. Edit it in barakoBrew. Render it with barakoPress. Deploy it anywhere.
A headless content platform. You own it and run it where you choose. Nothing is metered per seat, record or environment. Each product runs on its own. Used together, they take a site from an empty repository to a live server without a custom backend.
Ship the boring 80% on day one.
Content modelling, roles, versioning, scheduling, previews, SEO, redirects, images and feeds are already there. The interesting 20% is the part you were hired for.
Try the whole path
Creates a Next.js project with a compose file for barakoCMS, barakoBrew and barakoPress, seeded content, and working sign-in.
Shipping today
versions: nuget.org, npm and github releases
02 The path
Four stages, four documented boundaries
What passes between stages is an API you can read, not glue code you have to write. The labels on the line are the contracts.
This site is built on the same path. barakocms.com runs on barakoPress, and the blog is 8 posts from a barakoCMS instance.
count: delivery API, per request
barakoCMS
Content types defined at runtime. The API, the event log, the permissions. No frontend included.
barakoBrew
The console where editors write, model types, manage roles and run workflows.
barakoPress
The renderer for barakoCMS sites: pages from blocks, collections and docs trees, cached until the CMS says otherwise.
BaryoVM
Agentless deploys to VMs you own. AWS Lightsail provisioning is experimental, and Azure is planned. Replace it with your existing deploy tooling if you have any.
Publishing runs the other way. barakoPress caches every read until barakoCMS fires a signed webhook, so normal traffic never hits the database and a publish is live in one request.
03 The products
Where each product stands
Version numbers are read from the registries every hour. A stable API and a pre-1.0 site engine are described differently on purpose.
versions: nuget.org, npm and github releases, read every hour.
04 Inside the API
What you inherit on day one
Everything listed here is in the published release today. Nothing on this page is planned work.
Access, isolation, audit
Per-field sensitivity
Mark a field sensitive and the delivery API stops returning it, through one allowlist every public path goes through.
Capability-based authorisation
Roles hold capabilities, and you create your own. One built-in SuperAdmin role bypasses every check.
Multi-tenancy
One deployment, many clients, separate content and per-client member lists.
Event sourcing you turn on per type
The stream becomes the source of truth and the document is rebuilt from it. Every type keeps a change log either way.
Modelling, versions, scheduling
Content types defined at runtime
Add a type or a field without a rebuild or a migration.
Version history with rollback
Restore any content version, and the restore is written to the stream as an event of its own.
Scheduled publishing
A background sweeper publishes and unpublishes on time.
Signed preview tokens
Share a draft with a client through an expiring link.
SEO, images, feeds
SEO fields resolved in the response
Add the SEO fields to a type and title, description and canonical arrive resolved, with fallbacks, on every entry of it.
Image pipeline with on-demand widths
Request the width you render at. It is generated once and cached.
URL redirects
Stored with your content and served to your frontend, so a slug change need not cost you a ranking.
RSS and sitemap
Generated from the same content. Nothing extra to maintain.
05 Start
Start with what you need
One command per entry point. The first brings up the API, the console and the renderer together with seeded content and sign-in already working.
The whole path
Next.js project, compose file for barakoCMS, barakoBrew and barakoPress, seeded content, working sign-in.
The API only
Content modelling and delivery behind your own frontend. Swagger is the surface.
The site engine only
You already run barakoCMS and want the public site rendered.
Deploys only
Agentless deploys and hardening for any VM you own. AWS Lightsail provisioning is experimental, and Azure is planned. Nothing to do with content.