RAILS_MASTER_KEY in development

Is there any documentation on how to set up and use the master key for development?

Starting a new rails 5.2 app generates a key in config/master.key. That file is added to the .gitignore, so when other members of my team check it out, they do not have the key.

If another member of my team checks out the repo and attempts to run the server, they get an error that the key is missing.

Now, when they generate a key and put it in config/master.key, they get a ActiveSupport::MessageEncryptor::InvalidMessage error when trying to start up the rails server unless it is the exact key that was generated when the app was created.

It seems like rails is trying to decrypt some files (or something) and needs the key to do so. In the default 5.2 app, which files not in the .gitignore are being encrypted?

If the exact starting key is required to run rails, then why is it in the .gitignore, or even configurable at all?

Is there a way for different members of my team to use a different key in development? Is there a way to use a different key in production? Is there a way to change the key in production periodically?

Is all of this documented somewhere?

Sorry for all of the questions.

Thanks for your time!

  • Steve


I think perhaps there is 1 thing you are missing.

(someone stop me if I’m wrong here)

the purpose of the master.key is to decrypt .enc files, like config/credentials.yml.enc

This way, you can keep the encrypted versions of your yml (config) files in your repository, but not the secret key itself used to decrypt those files.

I think it’s discussed here in the 5.2.0 beta release notes:

In Rails 5.2, we’ve rectified the mess by deprecating the two different kinds of secrets and introduced a new shared concept called Credentials. Credentials, like AWS access keys and other forms of logins and passwords, were the dominant use case for secrets, so why not just call a spade a spade. So spade it is!

Credentials are always encrypted. This means they’re safe to check into revision control, as long as you keep the key out of it. That means atomic deploys, no need to mess with a flurry of environment variables, and other benefits of having all credentials that the app needs in one place, safe and secure.

In addition, we’ve opened up the API underlying Credentials, so you can easily deal with other encrypted configurations, keys, and files.

as well, this Engine Yard article I think explains some parts you are missing:


On your Rails 5.2 apps, what does this give you

rake -T |grep credentials


I think this has been fixed recently, see https://github.com/rails/rails/pull/30067#issuecomment-353364390 and Raise an error only when `require_master_key` is specified · rails/rails@3537321 · GitHub


Thanks for the reply, this looks promising!

Do you know if there is any documentation on this somewhere?

I seem to have gridlocked myself switching between branches. Now I can’t run rails even with the original key.

Do you know if there’s a way to turn off the encryption (at least temporarily)?

Thanks again!

  • Steve

Hi Jason,

Sorry, I didn’t see the notification for your reply.

Running rake -T | grep credentials doesn’t produce anything.

I see that I have a credentials.yml.enc file (although I have no idea what’s actually in it), I’m guessing that’s what the hangup is.

I guess I’m just confused about the whole process of having multiple people work on a repo at the same time, and have versions in production. At the moment, everyone on my team is just using the same master key. This is fine for development, but I haven’t found a way to change it at any point in the future. Are we meant to use the same key that is generated when rails is created throughout the entire lifecycle of this project? What would happen if we lost the key, or our current key was compromised?

I’m probably just not understanding something really basic and I will probably feel like an idiot when I figure out what that is, but thanks for taking the time to reply to me!

  • Steve