Why Andromeda

Adding a blog, documentation or a marketing site to a Rails app has usually meant one of three things: standing up a separate Astro or Next.js project, installing a CMS gem with its own tables and admin screens, or wiring up a headless CMS over HTTP.

Files are the interface

All three put content behind a database and a screen. That made sense while people were the only ones writing. They are not any more: much of the writing, editing and restructuring now happens with an assistant in the loop, and an assistant is good at exactly one thing here — reading and writing files in a repository it can already see.

Pointing it at a CMS means first building it an API or an MCP server, giving that its own authentication, and keeping it in sync with the schema. A second system, to serve the first.

Content as files needs none of that. Adding a post is adding a file, editing one is an edit, removing one is rm. The change arrives as a diff, is reviewed like any other change, and ships with the deploy that carried it — and the tool doing the writing needs no integration at all, because it already has the repository.

The schema still does its job: a missing title or an unparseable date fails the build with the file name and the line, so a generated file that is subtly wrong is caught before it is published rather than after. See Content and schemas.

Of everything in Astro’s design, this is the part that looks most like where things are going.

Alongside Astro, not against it

I like Astro, and I have a great deal of respect for the team behind it. For a static site I still reach for it.

But when a site needs sessions, forms, background jobs and a database, I want Rails. Andromeda exists so that this is not a choice between the two: the collection stays the same directory of files, parsed by the same engine Astro 7 uses, and moving it into Rails is a copy.