Stop Redeploying for Config Changes: The 5-Minute Rails Key-Value Store

We have all been there. You are five minutes into a dinner reservation when your phone buzzes. The marketing team wants to enable the "Holiday Sale Banner" right now, or an external API is down and you need to switch the app into a partial maintenance mode.

If your configuration is hardcoded in Ruby files or locked inside Environment Variables, making that change requires a commit, a build, and a deploy. That’s a 15-minute process for a 1-second change.

There is a better way. By leveraging ActiveRecord, we can create a lightweight, dynamic Key-Value store right inside your application database.

Here is how to implement a dictionary-style System Setting interface in Rails.

The Setup

We don't need a heavy gem like rails-settings-cached for simple use cases. We just need a table to hold keys and values.

1. The Migration

First, let's create a table to store our settings. We use text for the value to allow for long strings (like announcement messages) and ensure the key is unique so we don't get duplicates.

# db/migrate/20260115225500_create_system_settings.rb

class CreateSystemSettings < ActiveRecord::Migration[8.0]

  def change

    create_table :system_settings do |t|

      t.string :key, null: false

      t.text :value



      t.timestamps

    end

    add_index :system_settings, :key, unique: true

  end

end

2. The Model (With Syntax Sugar)

This is where the magic happens. A standard Rails model would force you to write verbose queries like SystemSetting.find_by(key: 'promo'). We can do better.

By defining self.[] and self.[]= class methods, we can treat our database table like a standard Ruby Hash.

# app/models/system_setting.rb

class SystemSetting < ApplicationRecord

  validates :key, presence: true, uniqueness: true



  # The Getter

  # Usage: SystemSetting[:maintenance_mode]

  def self.[](key)

    find_by(key: key)&.value

  end



  # The Setter

  # Usage: SystemSetting[:maintenance_mode] = "on"

  def self.[]=(key, value)

    setting = find_or_initialize_by(key: key)

    setting.value = value

    setting.save!

  end

end

How to Use It

Because we mapped the array accessors, the API is incredibly clean. You can use it anywhere in your controllers, views, or background jobs.

Setting a value (Console or Admin Panel):

SystemSetting[:global_announcement] = "Maintenance scheduled for 10 PM EST."

Reading a value (In your Application Layout):

<% if SystemSetting[:global_announcement].present? %>

  <div class="alert alert-warning">

    <%= SystemSetting[:global_announcement] %>

  </div>

<% end %>

Real-World Use Cases

1. The "Kill Switch"

Third-party integrations fail. If your SMS provider goes down, you don't want your background workers retrying thousands of times and crashing your Redis instance.

def send_sms

  return if SystemSetting[:sms_enabled] == "false"

  # ... execute sending logic

end

2. Dynamic Feature Flags

Want to let a specific feature go live at a specific time without a deploy?

if SystemSetting[:beta_features_active] == "true"

  render :new_dashboard

else

  render :old_dashboard

end

Leveling Up: Adding Caching

The implementation above is great, but it has one flaw: it hits the database every time you ask for a setting. If you put this in your application header, you are adding a SQL query to every single page load.

Since these settings rarely change, they are perfect candidates for Rails.cache. Here is the production-ready version:

class SystemSetting < ApplicationRecord

  validates :key, presence: true, uniqueness: true

  after_commit :clear_cache



  def self.[](key)

    Rails.cache.fetch("system_setting:#{key}") do

      find_by(key: key)&.value

    end

  end



  def self.[]=(key, value)

    setting = find_or_initialize_by(key: key)

    setting.value = value

    setting.save!

  end



  private



  def clear_cache

    Rails.cache.delete("system_setting:#{key}")

  end

end

Now, the database is only queried once. Subsequent requests pull instantly from memory (Redis/Memcached), and the cache is automatically busted whenever you update the record.

Summary

You don't always need complex infrastructure for configuration. Sometimes, a simple database table and a little bit of Ruby syntax sugar are all you need to make your application more flexible and your life easier.

Deploy the code once. Change the settings whenever you want.