Storytime keeps the CMS for content and the host app for everything else

A gem you add to an existing app, not a site you install

Storytime is a Rails 4+ CMS and blogging engine with a core focus on content, built and maintained by CultivateLabs.

The installation is a Gemfile line:

gem "storytime"

and then a bundle command. There is no standalone application, no admin panel to deploy separately and no separate database to keep in step. Storytime mounts into a Rails application you already have, which is the single most important fact about it.

The setup comes in three flavours, and the choice is about how much you want to review. The guided command line interface can set up your routes file, initializer, user model, copy migrations, migrate your database and copy views into your app, after you create a binstub:

$ bundle binstub storytime

and then:

$ storytime install

The automated setup goes through all of the same steps but instead of prompting for values it uses all the defaults, which the documentation says allows you to set Storytime up in seconds. It uses the same binstub and the same command with the -d option:

$ storytime install -d

The third option is manual setup, and the documentation links a wiki page for it.

After setup you start your Rails server and the dashboard is at `http://localhost:3000/storytime` by default. There is also a Heroku deploy button pointing at a separate storytime-example repository, which is the quickest way to see it running.

One operational note: to use the image upload feature, Storytime requires you to have Imagemagick installed on your system.

The separation of concerns is the whole design

The README states that Storytime is built around several opinions regarding the responsibilities and concerns of the CMS and the host app, and then it draws the line explicitly.

Storytime is responsible for editing content, copy and very basic formatting, where basic formatting roughly means things you could do in markdown. It is also responsible for enabling customization, extension and theming, and for basic CRUD administration of other Rails models.

The host app is responsible for complex page structure in HTML, styling in CSS, and interactions in JavaScript. It is responsible for app-specific details and customizations, and the example given is that Storytime tells the host app to send a post notification email while the host app decides how to send it and whether it should be in a background job. And the host app owns presentation details, since the project prefers to think of the host app as providing the theme for the Storytime site.

The two problems this solves are stated plainly. Building complex page structure and styling inside the CMS prevents the code from going into version control. And if complex page structure is in the CMS, it becomes much easier to break on production sites.

The two benefits follow. Code goes into version control and pages are much less likely to break. And combining admin and CMS features in one place gives site administrators a single place to edit content, rather than requiring both a CMS or blog and something like ActiveAdmin or RailsAdmin.

That second benefit is the one that changes how a team works. A Rails app with Storytime has one admin surface instead of two, and an editor never touches a template.

The feature set is small and each item has a stated purpose

The feature list is short, and every entry links to a wiki page describing it in detail, which tells you the documentation lives outside the repository.

Simple integration with Rails 4+ apps comes first, with setup available in a guided, automated or manual experience, whatever suits you. Multi-site support lets you manage multiple sites with one Storytime deployment. A quick access dashboard gives you Storytime's dashboard from anywhere on your site through a quick access menu.

Content-side features include inline text snippet editing, for snippets of content that can be reused throughout the site, and custom post types, to add post types that alter the functionality or appearance of posts. Admin of other Rails models lets you manage your models from the Storytime dashboard, which is the feature that makes it a general admin surface rather than only a blog.

Then two audience features. Email list building collects and manages emails using a simple view helper, and new post notifications send notifications to your site's subscribers whenever you publish a post. Built-in search lets you search through posts using built-in search adapters or request parameters.

Two things about that list are worth noticing. The email sending is the host app's job, Storytime only triggers it, and the search is described as built-in adapters or request parameters rather than a full search engine, which suggests it is a query layer over the database rather than an index.

The topic is a Rails gem rather than a standalone product, so the integration surface is a wiki and the code is the reference.

The security boundaries section is where the recent work went

The README carries a section on security boundaries that is written in a different voice from the rest of the document, and it is the part an operator should read most carefully.

Site admins manage content and site-local roles. Membership editing does not change users' global names, emails, passwords or account ownership. Existing global accounts cannot be added through the membership dashboard, and the instruction is to use a trusted host-side invitation or provisioning flow that obtains the account owner's consent. New accounts can still be created in the dashboard. The My Account link opens the host's reauthenticated account settings page, and you configure `account_settings_path` when it is not `/users/edit`, or set it to `nil` to hide that link.

Site creation is the other boundary. First-site setup remains available to an authenticated user, but creating additional sites is denied unless the host configures an explicit global provisioning privilege:

Storytime.configure do |config|
  config.site_creation_authorizer = ->(user) { user.platform_administrator? }
end

The documentation is careful about the trap here. `platform_administrator?` is an example host-defined privilege, not a Storytime method, and the instruction is explicitly not to implement this hook using a tenant's Storytime admin role. Site creation redirects locally after saving, and you configure routing and DNS for the new site separately.

The point of that whole mechanism is that a per-site admin role is a tenant-level role, and granting tenant-scoped users the ability to create new tenants would be a privilege escalation. Requiring a separate global predicate is the fix.

The media and homepage rules are equally specific. Media uploads accept JPG, JPEG, PNG, GIF and WebP images up to 10 MB, and active formats such as SVG or HTML are not accepted, with existing files unaffected. The instruction is to deploy image processor restrictions and request-body limits at the hosting layer as well, which is a reminder that the gem's validation is one layer and the server's limits are another. Homepage selections must be published pages or blogs on the same site, with unpublished or future-scheduled homepage content returning 404 to public readers while authorised owners and editors can preview it, and artifact responses using `Cache-Control: no-store`.

Maintenance, packaging and what the tree tells you

The repository is a Rails engine laid out the conventional way, with app/, config/, db/, lib/, spec/, bin/ and vendor/ directories, plus a Gemfile, a Gemfile.lock, a Rakefile, a storytime.gemspec and a Guardfile. The .rspec file holds the RSpec configuration, and there is a .ruby-version and a .tool-versions file alongside a .ruby-gemset, so the Ruby version is pinned for contributors. CI runs on CircleCI through the circle.yml file.

The dates need reading carefully, and they are the one thing a potential adopter should check before anything else. The repository is not archived and the last push was on 2026-10-01, so there has been recent work. But the tagged releases are old: v2.0.0 from 2015-04-13, v1.1.1 from 2015-01-30 and v1.0.7 from 2015-01-20.

So the picture is a project whose published gem versions stopped a decade ago, with maintenance continuing on the main branch rather than through new releases. That matters in a specific way, because adding `gem "storytime"` to a Gemfile resolves to the newest published version unless you point at a git source, and the newest published version is v2.0.0 from 2015. The security boundaries described above, and the recent push, are on the branch.

The screenshots directory and the wiki links are the rest of the story. This is a project whose documentation is split between a README that gives you the shape and a wiki that gives you the detail, and a set of wiki pages named for the features: Setup, Using the Quick-Access Menu, Multi-site-Support, Text-Snippets, Admin-of-Rails-Models, Using-Custom-Post-Types, Email-Subscriptions, Working-with-New-Post-Notifications and the post search page.

The licence is MIT, with MIT-LICENSE at the root, and the project is built by a company rather than a volunteer, which explains both the polish of the feature set and the lack of recent gem releases.

Where this sits against the other Rails admin options

The alternatives in a Rails codebase are three, and Storytime sits between them.

The first is doing nothing and building your own admin. That is what Storytime's own benefit list argues against, since combining admin and CMS features in one place gives site administrators a single place to edit content rather than requiring both a CMS and something like ActiveAdmin or RailsAdmin.

The second is ActiveAdmin, which is the closest comparison. ActiveAdmin is a Rails engine that gives you CRUD over your models with authentication and authorisation already solved. It does not give you posts, pages, media, theming, a public blog or a quick access menu, and it leaves the whole editing experience to you. Storytime gives up the breadth of ActiveAdmin for the content workflow, and the feature list of Admin of other Rails models is where it recovers some of that ground.

The third is a full standalone CMS on a different runtime, WordPress or Ghost for instance, with Storytime pointed at as a content source. That gives a better editing experience and a worse integration, because the content ends up outside your application and you have to fetch it at request time.

The honest assessment is that Storytime is for a specific shape of team: a Rails application with a marketing or editorial surface, a small content team, and a preference for keeping templates in the repository. If the content is the product, this is the wrong tool. If the content supports the product, it is a good one, and the separation of concerns is what makes it work.

The risk to weigh is the one the release dates describe. A project that has not published a gem release since 2015, while still pushing to the repository, is one where your Gemfile pin matters.

Editorial conclusion

Adopt Storytime if you run a Rails application and want editors to manage posts, pages and media through a real dashboard while your templates and assets stay in the repository and under your control. Skip it if you are starting a new site rather than adding an editor interface to an existing app, because the whole design assumes a host application already exists, and if you need a CMS with a large plugin ecosystem, since the feature set here is small and deliberate. Verify first that the gem still works on your Rails version, that Imagemagick is installed if you want image uploads, and how the site creation authorizer is configured, since additional sites are denied unless the host explicitly grants a global provisioning privilege.

Frequently asked questions

Official sources

1. CultivateLabs/storytime on GitHub
2. Issues
3. License: MIT
4. README
5. Releases