Ruby on Rails is a powerhouse for building web apps, but when it comes to content management, for some reason, Headless CMS just tend to be strung into the same sentence with Jamstackey frameworks like Next, Nuxt, and Svelte. Well, the folks at Renuo aren't too happy about that, and so we caught up with Alessandro to understand more about their work with DatoCMS and Rails.
The typical Rails setup doesn’t come with a built-in CMS approach, and most out-of-the-box solutions feel clunky, outdated, or overly opinionated.
That’s the exact problem Renuo, a Zurich-based web agency specializing in Rails, faced. They had multiple Rails projects where clients needed an intuitive way to manage their content. They could either build a CMS from scratch (painful, time-consuming, and not as polished as yours truly 💅) or try to retrofit something built for JS frameworks (which, given many of their projects are in the ruby realm, doesn't make sense).
Instead of settling for either option, Renuo took a different route. They built out dato-rails, an open-source Ruby gem that brings DatoCMS’s headless CMS experience seamlessly into the Rails ecosystem.
A short view back to the past
Renuo first encountered us at Ruby Day in Italy (pour one out for our now deprecated ruby client 🥃).
Although, ironically, their initial project with Dato wasn’t even in Rails—it was a Next.js site for a very familiar something-something-hamburger-chain-golden-arches client who needed a smooth way to manage video content. Alessandro remembered how DatoCMS stood out immediately because of its built-in video handling, structured content blocks, and intuitive editing experience. It solved problems they didn’t even realize were problems until they saw how easily we handled content.
Wait, why're we flexxing ourselves. This isn't about us, anyways, back to the point.
After that first encounter, Renuo started integrating DatoCMS into more projects, including their Rails-based web apps. The question they eventually encountered was: How do we make this work as seamlessly in Rails as it does in JavaScript frameworks like Next.js?
Unlike Jamstack frameworks like Next.js, Nuxt, or Astro—where SSG is a core feature—Rails applications are server-rendered. That meant Renuo had to rethink the way Rails fetched, stored, displayed, and, cached content from DatoCMS.
At first, they hacked together integrations for each new project. It worked, but it wasn’t scalable. Every time a new Rails project needed CMS functionality, they had to manually wire up GraphQL queries, manage caching, and figure out how to preview content for the editors. Meanwhile, developers using Next.js or Vue had official libraries that handled all of this automatically, considering our own packages for React, Next, Nuxt, and Astro are very heavily maintained.
When I started working with Dato on Ruby on Rails, there was no library to do so. I was jealous of all the libraries available for JavaScript frameworks.
That’s when they decided to stop reinventing the wheel, and came up with dato-rails.
Abstracting the pain away
With multiple projects using DatoCMS in Rails, it made sense to abstract the common logic into a reusable gem. Inspired by the way React and Vue handled content rendering, Alessandro and crew built DatoRails, a library that made working with DatoCMS in Rails as easy as it was in JavaScript frameworks.
I took a lot of inspiration from the React library—actually, I had it open on the next screen and was basically copying how they did things.
Instead of manually setting up GraphQL queries and parsing responses, developers could now:
Use prebuilt components for rendering structured text, images, and other content (inspired by Vue's approach to component handling).
Fetch data using a simple Ruby interface instead of manually constructing GraphQL requests.
Support draft and live preview modes without extra work.
Leverage Rails caching mechanisms to serve content blazingly fast without hitting the CMS on every request (more on that later!).
For Renuo, it meant less custom boilerplate and a much smoother DX with every new project.
Looking under the hood
The key to making DatoCMS work efficiently in Rails wasn’t just fetching content—it was optimizing how that content was served.
Since Rails renders pages dynamically, they needed a caching strategy that wouldn’t slow down the app. Instead of rebuilding static pages like Jamstack frameworks do, dato-rails hooks into Rails’ native caching mechanisms.
When content is fetched from DatoCMS, it gets stored in Rails’ built-in cache, making subsequent page loads nearly instantaneous. But how do you make sure the cache stays fresh?
Here’s where things get interesting. Instead of just caching individual pieces of content, Renuo built a custom publish endpoint. Whenever content is updated in DatoCMS, it triggers a hook that tells the Rails app to expire its cache and reload fresh content on the next request. While this handles the entire cache as a whole, should any of the projects scale beyond a managable point, Alessandro's pretty confident about implementing cache tags, that'd handle this with more granularity.
The result? Pages render in milliseconds—even though the content is dynamically managed.
While all this is cool for performance, there's a big part we haven't really touched upon at all. How the editors are affected with projects dealing with Rails.
One of the biggest goals of the approach was to bring feature parity with the way DatoCMS and React work via the official packages. If DatoCMS worked flawlessly in Next.js, why shouldn’t it be just as smooth in Rails?
With that in mind, there were 4 core things taken care of to make the usage as seamless as possible.
GraphQL Query Helpers to abstract away the complexity of making API calls
Components for common features like Structured Text, Images, and Videos, to make the content sourcing as alike to the JS packages as possible.
Draft Mode and Live Previews, for editors to have a seamless UX when using Dato, not sacrificing on any of the easy-to-implement features in the other packages, and
Asset Optimizations like lazy loading, resizing and format handling, to have parity with the imgix optimizations that Dato offers.
Bonus flex on top? Even real-time content updates are supported. Using Rails’ Turbo Streams, editors can edit content in DatoCMS and see the changes update on the frontend instantly.
👆 Dive in as Alessandro shows off everything dato-rails can do (while Ronak silently watches and pretends to understand everything that's going on 🫥)
Taking the OSS Approach
While dato-rails started as an internal tool for Renuo’s projects, they decided to open-source it for the wider Rails community to use.
Since then, we've also been recommending it to a few partners and devs working with Ruby, and it's been a highly appreciated package. For Rails teams that need strong CMS functionality, DatoCMS paired with Rails offers a clean, modern solution without the baggage of legacy Rails CMS options. Instead of dealing with clunky interfaces and outdated plugins, you get a dope experience that's got native support for all the juicy Dato features.
For now, the gem stays focused on what Renuo actually uses in production. It’s an open-source project, but they’re not chasing feature bloat—every addition has to serve a real need.
However, to wrap things up, a rather valid concern with many OSS packages is on the question of future maintainability. So I guess it's worth looking into how serious Renuo are on the topic of Ruby and on DatoCMS to gauge whether this package is going to be maintained a while from now.
So? How serious are they?
👇
Our own website is built with Ruby on Rails and DatoCMS. We didn’t even use a database—DatoCMS is our database.
✌️