Alexsandro Assis
← Build Journal
Content Ops 6 min

The role of Baserow as an editorial backend for multiple domains

How to use Baserow to centralize content management for multiple Astro sites while keeping organization, history, and operational scale.

When you manage just one blog, the WordPress editor or local Markdown files may be enough. But what happens when you decide to operate a network of 5, 10, or 50 sites? Complexity scales, and you need a central place to organize ideas, statuses, metadata, and publishing targets.

In this article, I show how I turned Baserow into an editorial backend for orchestrating multiple domains without locking the operation into a single CMS.

The need for a central hub

Managing multiple static sites can become a logistical problem if each one has its own login system, its own list of ideas, and its own mental repository. A Systems Builder’s goal is to reduce operational friction without losing control.

By centralizing ideas, drafts, publication statuses, and metadata in Baserow, I get a panoramic view of the editorial network without constantly switching tabs or rebuilding context for each site.

Why Baserow and not WordPress?

While WordPress can be used as a headless CMS, it brings a full application with it. For my use case, I needed less of a full CMS and more of a flexible editorial database. Baserow fits that role because it offers:

  1. Native API: simple to integrate with n8n.
  2. Customizable fields: I can create canonical_id, site_id, tags_json, and translation status fields without adapting to WordPress’s mental model.
  3. Table interface: ideal for quickly triaging dozens of content ideas.

How to structure tables for multiple domains

In my setup at a2au.xyz, the table structure in Baserow reflects the operational hierarchy:

  • Projects: defines the asset, such as the Lab or a niche site.
  • Domains: lists root domains and relevant settings.
  • Ideas: works as an inbox for drafts, captures, and research.
  • Content: stores the final text and its metadata before it is sent to GitHub.

This separation lets n8n discover which repository, language, and route each article should be sent to.

Integrating with the publication pipeline

Baserow does not publish the site on its own; it acts as the editorial source of truth. The flow looks like this:

  1. I change the status of a record in Baserow to “Approved for publication”.
  2. n8n detects this change via webhook or polling.
  3. n8n reads the record data, assembles the Markdown file, and pushes it to the correct repository defined in the sites table.

Content management with a solid base

Having a decoupled editorial backend gives me freedom to change frontend technology without losing data or reorganizing the whole operation. The content is not trapped inside the rendering engine.

If you want to scale content production with order, start thinking about the editorial base even before choosing your static site generator. In my lab, Baserow is one of the pieces that makes that growth sustainable.

Documentation and Tools