The path

Four products, each usable on its own. Used together they take a site from an empty repository to a live server, and every step from one to the next is an API you can read rather than glue code you write.

Model it in barakoCMS

barakoCMS is the API. Content types are defined at runtime, every change is an event on PostgreSQL, and permissions are checked per field. It ships no frontend: Swagger is its only built-in surface.

What passes on: content types and entries, over the admin API.

Edit it in barakoBrew

barakoBrew is the console editors and clients use. They write entries, model types, manage roles and run workflows. It holds no content of its own: everything it shows and saves goes through the barakoCMS admin API, so anything it does can also be done with a script.

What passes on: published entries, which the delivery API serves to anyone allowed to read them.

Render it with barakoPress

barakoPress is the site engine. It reads published entries over the delivery API and renders a blog you configure rather than fork: routes, type names, field names and site identity are settings. It caches every read and drops the cache when barakoCMS says something changed.

What passes on: a built site, ready to run on a server.

Ship it with BaryoVM

BaryoVM deploys that site to VMs you own, over SSH, with no agent on the server. It also hardens the host. It is general purpose and knows nothing about content, so an existing deploy setup can take its place.

Replacing a stage

Each boundary is a documented API or plain SSH, so any stage can be swapped for your own:

• Your own frontend instead of barakoPress, reading the same delivery API.
• Your own admin tooling instead of barakoBrew, calling the same admin API.
• Your own deploy pipeline instead of BaryoVM.

barakoCMS is the one stage the others assume. Choosing lists where to start depending on which stages you need.