The Developer's Paradox
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.
1. The "Indie Hacker" Way: Markdown + Git
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).
The Tech Stack:
- FrontMatter: To parse the metadata (title, date, tags).
- Redcarpet or CommonMarker: To convert Markdown to HTML.
- Rouge: For beautiful code syntax highlighting.
Why it’s great:
- 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.
2. The "Omakase" Way: Action Text + Trix
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.
# app/models/post.rb
class Post < ApplicationRecord
has_rich_text :content
end
Why it’s great:
- 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.).
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.
3. The "Pro" Way: Rails + a Headless CMS
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.
The Tech Stack:
- External CMS: Contentful, Strapi, or Spina CMS (a Rails-native CMS engine).
- The Logic: Rails fetches the content via an API and renders it.
Why it’s great:
- 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.
The "Must-Have" Checklist for any Rails Blog
Regardless of the architecture you choose, don't forget these three "One-Person" essentials:
1. The RSS Feed
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.
2. Meta Tags (The meta-tags Gem)
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.
3. Proper Caching
A blog is "Read-Heavy." Every time a user visits a post, Rails shouldn't have to re-render the whole template.
- Use Fragment Caching for the post body.
- Use Solid Cache (Rails 8) to keep your cache persistent even after a deploy.
Summary: Which one should you choose?
- 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.
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! 👇
SOCIAL SHARE CARD GENERATOR