Tools: The Best Ways to Build a Blog in Rails 8: From Markdown to Action Text

The Developer's Paradox ## 1. The "Indie Hacker" Way: Markdown + Git ## 2. The "Omakase" Way: Action Text + Trix ## 3. The "Pro" Way: Rails + a Headless CMS ## The "Must-Have" Checklist for any Rails Blog ## 1. The RSS Feed ## 2. Meta Tags (The meta-tags Gem) ## 3. Proper Caching ## Summary: Which one should you choose? As developers, we want to build our own blog because we want total control. We want to show off our stack. But the moment we start building a custom "Admin Panel," we stop writing content. If you are going to build your blog in Rails, you need to choose an architecture that matches how you actually want to write. Here are the three best ways to do it. If you prefer writing in VS Code or Obsidian rather than a web browser, this is the superior method. You don't even need a database for your posts. How it works: You store your posts as .md files in app/contents/posts/. Each file has "Front Matter" (YAML metadata at the top). This is the official Rails way. If you want a Medium-like editing experience where you can drag and drop images and see them instantly, this is for you. How it works: You use the built-in has_rich_text attribute. The Catch: Your content is stored as HTML fragments in your database. This makes "global find and replace" or migrating to a different platform slightly more annoying than Markdown. If you want a professional UI for your content team (or your non-technical co-writer) but still want to use Rails for the frontend, go headless. Regardless of the architecture you choose, don't forget these three "One-Person" essentials: In the age of algorithmic feeds, RSS is making a comeback. Rails makes this trivial with jbuilder. Do not ship without a /feed.rss route. If you want your posts to look good on Twitter/X or LinkedIn, you need OpenGraph tags. Use the meta-tags gem to easily set titles, descriptions, and "Social Images" dynamically for every post. A blog is "Read-Heavy." Every time a user visits a post, Rails shouldn't have to re-render the whole template. The best blog is the one you actually write in. Pick the one that gets out of your way. Are you building a custom blog or using a generator? Let's see your URLs in the comments! 👇 Templates let you quickly answer FAQs or store snippets for re-use. Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse COMMAND_BLOCK: # app/models/post.rb class Post < ApplicationRecord has_rich_text :content end Enter fullscreen mode Exit fullscreen mode COMMAND_BLOCK: # app/models/post.rb class Post < ApplicationRecord has_rich_text :content end COMMAND_BLOCK: # app/models/post.rb class Post < ApplicationRecord has_rich_text :content end - FrontMatter: To parse the metadata (title, date, tags). - Redcarpet or CommonMarker: To convert Markdown to HTML. - Rouge: For beautiful code syntax highlighting. - Version Control: Your blog posts are in Git. If you mess up an edit, just git revert. - Speed: No database queries. You can cache the parsed HTML in memory or use Solid Cache. - Portability: If you ever leave Rails, your content is just standard Markdown files. - Image Handling: Rails handles the active storage uploads, resizing, and embedding for you. - The Editor: The Trix editor is clean, minimal, and battle-tested by Basecamp. - Integrated: It works seamlessly with the rest of the Rails ecosystem (ActionBroadcasting, etc.). - External CMS: Contentful, Strapi, or Spina CMS (a Rails-native CMS engine). - The Logic: Rails fetches the content via an API and renders it. - Separation of Concerns: You don't have to build an image uploader, a preview system, or a draft/publish workflow. The CMS handles it. - SEO Tools: Most headless CMSs come with built-in SEO fields and validations. - Use Fragment Caching for the post body. - Use Solid Cache (Rails 8) to keep your cache persistent even after a deploy. - Choose Markdown if you are a solo developer who loves Git and hates databases. - Choose Action Text if you want the most "Railsy" experience and like writing in the browser. - Choose Spina or a Headless CMS if you want a polished admin experience without building it yourself.