Documentation

Practical product docs for setting up, mapping, editing, and operating BaseBuddy.

Docs/Postgres CMS

Postgres CMS

Learn how BaseBuddy works as a self-hosted Postgres CMS for existing schemas, mapped fields, and safe content editing.

A CMS for existing Postgres schemas

BaseBuddy is also a Postgres CMS. It is built for projects where the database already exists and the content model should stay under your control.

Instead of creating a new CMS schema for posts, pages, authors, taxonomy, media, and workflow state, BaseBuddy lets you map the tables and fields you already use.

How BaseBuddy thinks about Postgres

BaseBuddy separates storage from editor meaning.

LayerWhat it answers
Storage contractWhere does the value live, what shape is it, and can it be patched safely?
Semantic roleIs this value acting as title, body, slug, status, author, category, tag, or media?
UIWhich editor control should appear for that value?

This lets BaseBuddy work with direct columns, JSON paths, relations, helper rows, mapped media references, and read-only values without pretending every schema is the same.

Storage contract and UI is the deeper reference for those shapes.

What BaseBuddy does not take over

BaseBuddy stores its own setup data, but your content remains in your database.

  • It does not rename your content tables.
  • It does not reshape your columns during editing.
  • It does not store install database credentials in project rows.
  • It does not rewrite unchanged fields.
  • It does not silently convert one storage shape into another.

That makes it useful for existing Postgres products, internal tools, SaaS content areas, documentation systems, directories, marketplaces, and editorial workflows where the app database already matters.

Write behavior

Normal saves are intentionally small.

Editor changeDirty mapped fieldPatch saved storagetargetExisting Postgres row

When you click Save, BaseBuddy writes the mapped fields that changed. Publish, Unpublish, and Archive are separate workflow actions with their own permission checks.

Safe editing model and Publishing workflows split those two paths clearly.

Start carefully

Use a development database or production copy first. Map one posts table, open one post, change one low-risk text field, save it, and inspect the row.

Then add relations, media, files, SEO, redirects, permissions, and production deployment once the basic path is proven.

For setup, start with Installation, Configuration, and Projects and mappings. For the hands-on first test, use How to safely edit your first post.