AstroBaaS is open source: a self-hosted, MCP-ready CMS and backend on Astro

It's out

Today, 23 September 2026, I'm releasing AstroBaaS as open source. It's a self-hosted, TypeScript-native headless CMS and backend built on Astro, with a content admin built in — and the whole thing runs as one Node process.

It's licensed GPL-3.0-or-later, and it represents about a year of work: roughly 1,000 commits and 100 pull requests. I'm proud of it. I'm also very aware that it's an early release, so this post covers both sides: what it does today, and what it doesn't do yet.

Why I built it

I build a lot of websites, and I build them fast. Every one of them needs the same thing behind it: somewhere to keep posts, pages and media, an admin a client can actually use, and an API the frontend can read from. I didn't want to stitch that together from scratch each time, and I didn't want to hand it to a hosted service I don't control.

I've written before about why Astro feels like the framework I'd been waiting for. So I built the backend I wanted on top of it: TypeScript all the way through, self-hosted, and simple to run.

There was a second reason. More and more, the thing writing content isn't only a person in an admin panel — it's an AI agent. I wanted a backend where that's a first-class path, not an afterthought.

AstroBaaS isn't a weekend experiment. It has been running in production for months, behind 2 small e-shops and more than 10 business websites and blogs.

What it does

The short version: content, an admin, an API, and the plumbing around them. All of it runs in that single Node process — there's no separate admin app to host and no extra services to wire together.

• Content: posts, pages, media, revisions and autosave, plus custom types and taxonomies for everything that doesn't fit a blog post.
• API: a REST API with scoped bearer keys, CORS, and signed webhooks. It publishes its own /openapi.json and an /llms.txt.
• Developer tools: a typed SDK (astrobaas/client) and a CLI.
• Commerce, if you want it: products, stock, orders, shipping and tax are part of the core, but switched off by default.
• Storage: three drivers — lowdb, libSQL as a document blob, and libSQL relational.
• Security defaults: a strict CSP, sanitised HTML and rate limits. And a production build refuses to run with the default password or placeholder secrets.
• Deployment: a Dockerfile, plus ready-made systemd, nginx and Caddy configs.

Built for AI agents: the MCP server

The part I'm most excited about is the MCP server. It ships as its own zero-dependency package, astrobaas-mcp, so AI agents can read and write your content through the Model Context Protocol. Point your MCP client at your AstroBaaS instance with an API key:

{
  "mcpServers": {
    "astrobaas": {
      "command": "npx",
      "args": ["-y", "astrobaas-mcp"],
      "env": {
        "ASTROBAAS_URL": "https://cms.example.com",
        "ASTROBAAS_KEY": "abk_..."
      }
    }
  }
}

In practice, that means the same agent that helps you build a site can also put the content into it — drafting posts and pages straight into the CMS, where they sit next to everything written by hand in the admin.

Because the REST API uses scoped bearer keys, you decide what an agent's key is allowed to touch.

Who it's for

AstroBaaS is a good fit if you build sites quickly — including the "vibe-coded" ones — and you want a ready-made, MCP-ready backend for the content instead of inventing one per project. I wrote about the weaknesses of vibe-coded websites a while ago; a solid, boring backend with sane security defaults is one way to take some of those weaknesses off the table.

It's also for anyone who simply wants to own their CMS: your server, your data, one process to run.

What's still missing

I'd rather you hear the limits from me than discover them on your own:

• It's an early release. Pre-alpha, to be precise. Expect things to change.
• No external security audit yet. The defaults are strict, but nobody outside the project has audited it.
• Payment providers aren't verified against their live sandboxes yet. The commerce core is there; the provider integrations still need that round of testing.
• Plugins are compiled in at build time, not installed from a dashboard. That one is by design, but it's worth knowing up front.

Try it

The libraries and the CLI are on npm:

npm install astrobaas@alpha

To run the CMS itself, clone the repository:

• github.com/operator888/astrobaas — the code and the issue tracker

If you try it, I'd love to hear how it goes. Found a bug, hit a missing feature, or have an idea? Open an issue — at this stage, every one of them helps. And if you'd rather talk directly, get in touch.

About a year of work, around a thousand commits, and it's finally out in the open. Thanks for reading — now go break it.