// the take
A Rails gem for storing global key-value settings in the database with a typed DSL (string, integer, array, hash, boolean, etc.) and an automatic caching layer on top. It's aimed at any Rails app that wants an admin-editable settings table instead of hardcoded config, and it's mature enough to be used by Mastodon, Forem, and over a thousand other repos.
The field DSL is genuinely nice — typed fields with defaults (including lambdas), validations via standard ActiveModel `validates`, readonly fields for pre-boot config, and a clean extension point for custom types via `RailsSettings::Fields::Base`. The caching model is well thought out: it batches all keys into one cache read, memoizes per-request via `ActiveSupport::CurrentAttributes` to avoid redundant cache/db hits, and lets you swap in Redis or any `ActiveSupport::Cache::Store`. It's also properly battle-tested — long production history, CI with coverage tracking, and a documented migration path from the old 0.x scoped-settings API.
Every single setting write invalidates and reloads the entire settings cache (all keys, not just the one changed), which the docs themselves warn against using for frequently-updated keys — this is a hard scaling ceiling, not an edge case, if you ever want a 'last seen' counter or similar living next to real config. There's no admin UI included; you're expected to hand-roll the controller and form yourself (the README's example admin controller doesn't even strong-param-protect `notification_options` safely for arbitrary YAML-shaped hashes). Nothing in the gem encrypts sensitive values at rest, yet the README's own examples store SMTP passwords and OAuth client secrets as plain settings rows — fine for feature flags, risky if you follow the docs literally for credentials. And the 0.x → 2.x API break (scoped settings removed) means older integrations need real migration work, not just a version bump.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →