Why does Google point to 5 year old articles about Railties?

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com

Sometimes Google disappoints. If you search for “gem plugins railtie” the first link is to an article that is 5 years old. Is there truly no better information? That article says:

Railtie plugins are easy to turn into gem plugins for Rails. This makes them easy to distribute, manage, and upgrade. The first thing you need is a gem. If you don’t have a gem yet, you can create a new gem easily using Bundler. Just run bundle gem my_new_gem and Bundler will generate a skeleton gem and gemspec that follow gem best practices. Once you have a gem, just make sure that your Railtie subclass is defined when lib/my_new_gem.rb is loaded. You can define the Railtie in a separate file and require that file, or define it directly. Last, add a dependency on the Rails gem (~>3.0) to your gemspec.

If your gem is also a plain Ruby library, and you don’t want to depend on the Rails gem, then you can put your Railtie in a separate file, and conditionally require that file inside your main library file.

# lib/my_new_gem/my_cool_railtie.rb
module MyNewGem
class MyCoolRailtie < ::Rails::Railtie
# Railtie code here

# lib/my_new_gem.rb
require ‘my_new_gem/my_cool_railtie.rb’ if defined?(Rails)

This ensures that your gem can be loaded (without the Railtie) if it is loaded outside the context of a Rails application.

This article from 2012 offers slightly more info on the differences between gems, railties, and engines:


Plugins are an alias for Gems. However, there is another layer to this discussion. Prior to Rails 3.2 and officialy in Rails 4 there were things were officially called “plugins.” Plugins were usually smaller than Gems and lived inside vendor/plugins. Essentially no one uses them anymore besides Heroku because they love raising deprecation errors in current applications. You can use rails plugin new which will generate a new gem that’s connected to rails via railties.

Use Cases



The name itself defines its purpose. A “railtie” provides a connector for external code to tie into Rails. It allows you do things like define configuration for Rails or add initializers. Here are some common use cases suggested from the Railtie docs:

configuring a Rails framework for the application, like setting a generator
adding config.* keys to the environment
setting up a subscriber with ActiveSupport::Notifications
adding rake tasks

ActiveRecord, ActionPack, ActiveSupport are all connected to rails via railties. Railties connect separate sections of code into Rails. Here is an real life example of a simple Railtie in the wild:

module Cashier
class Railtie < ::Rails::Railtie
config.cashier = Cashier

initializer "cashier.active_support.cache.instrumentation"
ActiveSupport::Cache::Store.instrument = true

Use Cases

Connecting non rails code to rails


"Engines" are actually a railtie subclass. They can do everything a railtie can do and more. Engines are essentially self contained rails applications. They can have all their own models, controllers, views, routes, and internal code. Engines can be packaged as gems. You can do everything in an engine that you can do in your application. That's because your Rails application is actually just an engine. You can generate a new engine like this: rails plugin new foo --mountable (Yes plugin is confusing.)



Use Cases

You want make a self contained rails application that can be redistruted.
You want to decompose your large rails application into smaller components

The joke about plugins is useful.