Ruby on Rails CMS platforms: a guide for engineering leads

Three CMSes turn up in almost every Rails shortlist: Refinery, Spina, and Comfortable Mexican Sofa. Two shipped Rails 8 support in the last twelve months. One has been dormant since 2020 and is being revived through a community-led fork. The HTTP Archive Web Almanac frames a CMS as platform plus ecosystem, and the ecosystem signal is what most listicles hide. We grade the field on the ecosystem first, then rank on features, and name the option most shortlists miss.

Why Rails CMS choice looks different now

Rails 8 has compressed the gap between custom admin and CMS engine. The Rails 8 release in November 2024 shipped Action Text, Solid Queue, Solid Cache, and Propshaft as defaults. A new Rails app now arrives with rich text editing, background jobs, asset pipeline, and authentication generators out of the box. The primitives a CMS used to provide are now in the framework.

That shift changes the buying question. The old question was about features. The new question is different: do we even need a CMS engine, and if so, which engines still keep pace with Rails 8 in production? Most shortlists skip the second half.

Rails developer adoption has held steady. The Stack Overflow Developer Survey 2024 puts Ruby in the top earnings band globally, which keeps the Rails ecosystem viable but small enough that maintainer attrition is a real risk. CMS dormancy is the buying risk most teams fail to underwrite. A gem that was the top pick three years ago can stall, miss two Rails versions, and become a security liability before the team notices.

We use four buying criteria across this guide. Maintenance signal. Rails 8 readiness. Editor experience for non-engineering content owners. Delivery model, classic or headless. Anything outside those four is feature noise.

The four criteria also do most of the work in our technology strategy engagements with engineering leaders. Pick a CMS that fails on any one of them and the team is rebuilding inside two years.

A scorecard for evaluating any Rails CMS

A four-column scorecard answers the question feature lists cannot. Each row names a criterion, the signal to measure, the red flag, and the reason it matters. We grade every Rails CMS through this lens before reading vendor marketing.

The order matters. Maintenance and Rails version are gating criteria. A CMS that fails either is dropped from the shortlist before the team evaluates editor experience or features. Only platforms that clear both gates move into the feature comparison.

This is the same scorecard we apply to the web development practice we run when a client asks for a CMS pick alongside a build. The two gating criteria do most of the filtering work. Editor experience and customisation depth do the rest.

Refinery CMS, when it fits

Refinery is the lowest-risk Rails CMS for teams that want convention over invention. The Refinery GitHub README declares support for Rails 6.1 through 8.1+ and Ruby 3.x to 4.x. That alone places Refinery in the maintained tier in 2026.

The editor is simple. Non-engineering content owners can update pages, upload images, and manage navigation without engineering help. The admin shows its age compared to Spina but the workflows are predictable. The plugin model handles most common extensions including image galleries, contact forms, and SEO-friendly URLs.

Refinery is opinionated about being a classic CMS. Content and frontend live together inside the Rails application. Headless delivery is possible through custom controllers but is not the default path. Teams that need API-first content delivery should pick Alchemy or pair Rails with a SaaS headless CMS instead.

The project profile that fits Refinery is small to mid-sized business sites, marketing pages, and content-driven sites where editor simplicity and Rails-native convention matter more than headless flexibility. We have shipped Refinery installs that ran for six years without a structural rewrite. The conventional path is what makes that possible.

Where Refinery breaks is at the high end. Complex content modelling, structured component libraries, and multi-site setups all push past Refinery's design intent. For those profiles, Alchemy or Locomotive will read as a better fit.

Spina CMS, when it fits

Spina ships the cleanest editor experience in the Rails CMS field. The admin is visually polished, the page structure is component based, and non-engineering editors learn it in a single session. Spina v2.20.0, released on 5 May 2025, added Rails 8 and Propshaft support and is the cleanest 2025 maintenance signal in this comparison.

The Spina component model lets developers define structures once and editors assemble pages from them. Themes drive the visual structure. Content lives separately from layout. The result is a tighter editor flow than Refinery's page-level editing.

Spina suits portfolios, microsites, marketing pages, and small business sites where the editor experience is the project's main constraint. Spina Shop extends the engine to commerce, though most teams pair Spina with Solidus or a SaaS commerce layer when commerce is the primary product.

Spina is deliberately narrow. The platform does not try to be a structured content service. Multi-site management is possible but not the design centre. Complex content libraries with hundreds of structured records will push the editor beyond comfort. Headless delivery is available through a community GraphQL plugin but is not first class.

The case to pick Spina is editor sophistication on a budget Rails-native stack. The case against is content complexity. When the content model outgrows pages with components, the team should be looking at Alchemy or a SaaS headless CMS.

Alchemy CMS, when it fits

Alchemy is the choice for teams managing structured content at scale. The Alchemy GitHub repository describes the engine as component based with optional headless delivery. Developers define content elements in code. Editors assemble pages from those elements through a controlled admin.

The element model separates content modelling from presentation. The same content elements render on a server-side Rails view, ship through a JSON API to a Next.js or Vue frontend, or feed a native mobile app. That hybrid flexibility is the reason Alchemy keeps appearing on shortlists for catalogs, landing-page factories, and multi-channel content operations.

Internationalisation is first class. Multi-locale workflows ship with the engine. Translation status, fallbacks, and locale-specific content all work without third-party plugins. Localised sites that fail on Refinery or Spina often work on Alchemy without changing the architecture.

The cost is editor learning curve. Alchemy assumes the editor understands the component model the developer has set up. Marketing teams that drag and drop on Spina will need training to work with Alchemy elements. The structure is the strength and the price.

Alchemy fits when content is the product and the content team is willing to invest in a structured workflow. SitePoint placed Alchemy and Refinery as the headline pair in its Rails CMS comparison, and that framing still holds in 2026 with Alchemy as the structured option.

Comfortable Mexican Sofa and the dormancy question

Comfortable Mexican Sofa has been dormant since 2020. The GitHub wiki notice on the project confirms this and points to ComfortableMediaSurfer as the community-led revival. Both names refer to the same codebase. The fork is the active path forward.

What dormancy means in practice is unpatched dependencies, no official Rails 8 support, and no roadmap. A team that adopts the original Sofa repo in 2026 will spend engineering hours on Rails compatibility work the maintainers are not doing. ComfortableMediaSurfer addresses some of this but is still community-paced. Both should be treated as risk-managed adoptions rather than default picks.

The original strengths still exist. Developer-driven configuration. Block-based page composition. Tight embeddability inside an existing Rails application. Those strengths made Sofa the right choice for SaaS products that needed a content module without imposing a full CMS on the user. The fork preserves that design.

The decision rule for either Sofa or MediaSurfer is straightforward. Pick it only if the original design fit matters more than the dependency risk. The team must also be willing to take on the maintenance load the original maintainers stopped carrying. Otherwise, Refinery or Spina will deliver a similar architectural profile with a current maintenance signal.

If a team already runs Sofa in production, the live question is migration timing, not abandonment. We carry that conversation across software maintenance engagements when a client asks whether to migrate or to take on the fork. The answer almost always turns on the Rails upgrade plan, not the CMS itself.

Locomotive, Camaleon, and the rest

Three more options deserve a brief look before the no-CMS-engine question. Locomotive remains the multi-site choice. Camaleon is the WordPress migration path. Fae and RailsPress are newer entrants worth tracking.

Locomotive supports multi-site management from a single backend. Several websites can share one engine while keeping branding and content separate. The platform runs as open source or as a hosted freemium product, with paid tiers starting around USD 19 per month per site. Multi-site is the strongest pitch. Single-site teams will find Locomotive heavier than the alternatives.

Camaleon brings a WordPress-familiar workflow to Rails. The plugin model, widget-based publishing, and a Spanish-language admin make it a natural choice for teams migrating from PHP-based stacks. Optional commerce support handles light catalog and storefront use cases. Plugin quality varies, so teams should evaluate any extension before committing.

Fae CMS is designed around structured objects rather than pages. The engine works alongside decoupled frontends and GraphQL APIs, scaffolding admin functionality quickly while leaving developers full control over business logic. Fae fits when the admin is the product surface and the public site is built separately.

RailsPress is a Rails 8 native blog engine and CMS released in 2026. The engine ships posts, CMS blocks with inline editing, and an Entity System for managing any model through the admin. It is too new for a strong maintenance track record. It is still worth shortlisting for greenfield Rails 8 builds where Action Text plus a small admin engine is the target architecture.

None of these three replaces Refinery, Spina, or Alchemy as a first pick. They sit one tier down and fit narrower profiles.

When to skip a CMS engine entirely

For sites under 50 pages, the right answer might be no CMS engine at all. Rails 8 ships Action Text, Hotwire, ActiveStorage, and a Devise-compatible authentication generator. Those four primitives cover most of what a marketing site CMS needs.

Action Text plus Trix gives editors a rich text experience that compares well to the Refinery or Spina editors. Hotwire enables inline editing without a JavaScript framework. ActiveStorage handles uploads with first-class S3 and other cloud storage support. The result is a publishing surface that runs in 200 to 600 lines of custom Ruby and ERB across a typical marketing site.

The cost is engineering time. Building the admin takes one senior Rails engineer two to four weeks for a marketing site, plus a small amount of design work. The benefit is no dependency on a CMS maintainer. The team owns the code. Rails upgrades are a normal Rails upgrade rather than a CMS compatibility audit.

The three project profiles where custom wins are clear. A single-language marketing site under 50 pages where the team is small and the content team is the same as the engineering team. A founder-led startup that needs to ship a marketing site fast and does not want a third gem in the dependency graph. We see that profile often in MVP engineering for product founders. A regulated industry build where every dependency is a compliance review item and a smaller code surface is easier to defend.

The custom path loses when the content team grows past five non-engineering editors, when the site crosses 100 pages with structured content, or when multi-channel publishing enters the roadmap. At that point a CMS engine pays for itself within the first year.

We ship custom admin builds alongside CMS adoptions across Ruby on Rails development engagements. The build versus adopt call is the first conversation we have with a client when content is in scope.

Headless Rails when SaaS CMS wins

For sites above 500 pages, the SaaS headless path often beats a Rails-native CMS. Sanity, Contentful, and Strapi handle editor experience and content modelling. Rails handles rendering, business logic, and the data layer through a JSON or GraphQL fetch.

The case for SaaS headless rests on three signals. The editorial team is large, with ten or more non-engineering content owners. Content publishes to multiple channels: web, mobile app, marketing automation, partner feeds. The editor user experience is the project's main risk, not the engineering work.

The case against rests on different signals. Content volume drives unit economics, since SaaS CMSes charge per record or per API call. Data residency rules block third-party storage, common in regulated and EU public-sector work. Vendor lock-in is a board-level concern.

Alchemy occupies the middle ground. The engine supports a hybrid mode where content lives inside Rails but ships through a JSON API to any frontend. Teams that want headless flexibility without the SaaS dependency often pick Alchemy as the bridge.

The Rails-as-renderer pattern pairs naturally with API development we ship for Rails applications and the cloud architecture we have built for Rails. The architectural choice cascades into hosting, caching, and the build pipeline. We make that decision early because retrofitting it costs three times as much.

Frequently asked questions about Ruby on Rails CMS

Is a Rails CMS still a good choice?

Yes for content-driven Rails applications under 500 pages, with caveats. Refinery and Spina are actively maintained and support Rails 8. Alchemy works for structured content at scale and supports hybrid headless delivery. For large multilingual sites with dedicated content operations teams, a SaaS headless CMS paired with Rails as the rendering layer often wins on editor experience. The decision turns on three signals: site size, content model complexity, and the size of the non-engineering team that will manage content day to day.

Which Ruby on Rails CMS supports Rails 8?

Three CMSes ship official Rails 8 support as of mid-2026. Refinery declares Rails 6.1 through 8.1+ compatibility in its README. Spina v2.20.0, released in May 2025, added Rails 8 and Propshaft support. RailsPress, a newer Rails 8 native engine, was built against the Rails 8 release directly. Alchemy is current on Rails 7 with Rails 8 work in progress. Locomotive, Camaleon, and the original Comfortable Mexican Sofa are not officially Rails 8 ready and need careful evaluation before adoption.

Should we use a CMS or build custom?

For marketing sites under 50 pages with simple content models, a custom admin built on Rails 8 plus Action Text often beats every CMS engine on cost and maintenance. Action Text gives you rich text and media. Hotwire gives you inline editing without a JavaScript framework. ActiveStorage handles media. A small admin scaffold built on these primitives runs from 200 to 600 lines of code. For sites above that scale or for non-engineering content teams of five plus, a CMS engine pays for itself within the first year.

Best Rails CMS for non-technical editors?

Spina has the cleanest editor experience in the Rails CMS field as of 2026. The admin is visually polished, the page structure is component based, and non-engineering editors learn it in a single session. Refinery is straightforward and stable but the admin shows its age. Alchemy is structured and powerful but assumes the editor understands the component model the developer has set up. Comfortable Mexican Sofa requires more technical comfort than the others and is harder to recommend in 2026 given the dormancy of the original repository.

Is Comfortable Mexican Sofa still maintained?

The original Comfortable Mexican Sofa repository has been dormant since 2020. The wiki notice on the GitHub project confirms this. A community-led fork called ComfortableMediaSurfer is the active revival and is the only path forward for teams still committed to the codebase. We treat adoption of either as a risk-managed decision: budget for the maintenance work the original maintainers are not doing, and assume Rails 8 compatibility will require local patches.

Can we use a headless CMS with Rails?

Yes, and for some project profiles it beats a Rails native CMS. A SaaS headless CMS such as Sanity, Contentful, or Strapi handles the editor experience and content modelling. Rails handles rendering, business logic, and the data layer. The pattern wins when the editorial team is large, when content publishes to multiple channels, or when the editor user experience is the project's main risk. The pattern loses when content volume drives unit economics or when data residency rules block third-party storage.

Picking the right Rails CMS, the short version

Two failure modes account for most regretted CMS choices on Rails. A team adopts a dormant gem and spends 18 months patching what the original maintainers no longer ship. A team builds a custom admin that drifts into something only one engineer understands.

We ship Rails 8 applications with the CMS or custom admin layer that fits the project profile. Senior Rails engineers. Rails 8 expertise. Maintenance discipline that keeps the code shipping for years after launch. Engagement starts within two weeks of the first call.

Ready to ship a Rails CMS that survives the next upgrade? Talk to our Ruby on Rails engineering team.