Rails 6.1: How Do I Access Environment-Specific Credentials Without Duplicating Configuration?

Rails’ credentials are treated differently compared to your old secrets.yml file. In a secrets.yml file you could merge defaults into each environment, but with credentials Rails doesn’t perform that kind of merge automatically.

Why Your Code Returns Nil

When you call:

RUBYCopied
Rails.application.credentials[:secret_key_base]

Rails looks for a top‑level key named :secret_key_base in the overall credentials. In your case, since you’re scoping keys under environment names (e.g. development, alpha, etc.), there isn’t a top‑level key available. That’s why you need to do:

RUBYCopied
Rails.application.credentials[Rails.env.to_sym][:secret_key_base]

to get the environment‑specific key.

Recommended Best Practice

Rails 6 encourages you to use single credentials files that are unscoped or use environment‑specific credentials files. In particular, the best practices are:

1. Use a Flat Credentials File per Environment:
   If you want credentials to be accessed without an extra lookup, consider having a flat (unscoped) structure. For example, in your config/credentials/production.yml.enc you can have:

   YAMLCopied
   secret_key_base: xyz
   sol_encryption_key: 456
   # other production-only keys…

   Then you can simply use:

   RUBYCopied
   Rails.application.credentials[:secret_key_base]

2. Leverage Environment-Specific Credentials Files:
   Rails 6 allows you to have multiple credentials files (one per environment). You can create files such as:

   • config/credentials/development.yml.enc
   • config/credentials/production.yml.enc
   • etc.

   This way, you don’t need to merge defaults manually. Each file is self-contained for an environment. Rails will automatically load credentials for the current environment.

What to Do in Your Case

• Option 1: Flatten the Structure
  Remove the environment key nesting so that keys like secret_key_base are at the top level. This is the simplest solution if you don’t mind duplicating values across environments (or using Ruby’s ERB). For example:

  YAMLCopied
  # In your production.yml.enc
  secret_key_base: xyz
  sol_encryption_key: 456

• Option 2: Use Environment-Specific Files for DRY Configuration
  If you want to avoid duplication, maintain a common file for defaults and then merge or reference them when building each environment’s credentials. Rails doesn’t merge these files for you out of the box, so you might need to load a common file and merge it into the environment‑specific credentials at runtime. However, the Rails convention is to keep each environment’s credentials self-contained.

Summary

There is no built‑in merging of default keys in Rails credentials as there was with secrets.yml. The recommended approach is to use environment‑specific credentials files (or flat credentials files without nested environment scopes) so that Rails can access keys like secret_key_base directly. This aligns with Rails conventions and ensures that internal keys (like secret_key_base) are set in the way Rails expects.

By restructuring your credentials as described, you can avoid having to call Rails.application.credentials[Rails.env.to_sym] throughout your application.