Ask A Question

Notifications

You’re not receiving notifications from this thread.

Use .ENV instead of Secrets.yml for keys

Rob Sturcke asked in Servers

Regarding around time area 3min for Direct File Uploads to S3: Part 2, I was wondering if I could just use .ENV since I'm using this as an example for my Github and Heroku. Instead of putting my keys into secrets.yml and using shrine.rb pointing to them, could I just add .ENV gem and point to my keys from my application.rb?

Or do the Rails.application.secrets.aws_secret_key... have to be in Shrine.rb in order for Shrine to work properly with S3? I found Paperclip fairly easy to use with .ENV but a little confused with Shrine.

Reply

You can use <%= ENV["AWS_SECRET_KEY"] %> in your secrets.yml to grab environment variables. For example:

production:
  aws_secret_key: <%= ENV["AWS_SECRET_KEY"] %>

The reason why you should continue using secrets.yml is because this provides a consistent interface if you stick with Heroku or migrate to your own server and choose to hardcode the values in a file on the server. Your Rails app doesn't have to care either way and you are free to use ENV variables or hardcoded values interchangeably.

Reply

Obviously make sure you don't commit your 'secrets.yml' file to any publicly accessible repo if it contains sensitive data ;)

i personally used Chris's shrine video and stored images and files locally when in development. Then put my S3 credentials in Heroku's settings so my production site uses S3. Yeah its manual but least i know they are only in one place.

Reply

Of course, just not a fan to reset my config/secrets.yml from the commits on projects/examples. I found .ENV a very useful tool with gems like Paperclip working along with S3 but Shrine seems to add that extra step to use .ENV. I'll definitely look into how to do that Heroku credentials manually to see how it works.

Reply

Yeah, Heroku's stuff is easy because you can say heroku config:set AWS_SECRET_KEY=xxxxxxxxxxxxx and it will set the ENV variable for you, and voila! You've got ENV variables set.

Much easier than doing that on your own server since nginx doesn't let you set ENV variables in your server config. When you've got your own server, it's easier to write the secrets.yml file on the server only in the shared directory between deploys and then symlink it during deploy instead rather than using ENV variables.

Reply

Hi Chris I'm upgrading an old app starting on 5.2. For some reason secrets file is not reading the .env variables so I had to hardcode it for development. But what about production as we are using Heroku and we use env for it. the <%= ENV["AWS_SECRET_KEY"] %> is not getting read by shrine. Thank you.

Reply

Rails 5.2+ switched to using Credentials instead of secrets.yml. I would recommend using that going forward.

That said, if you still want to use .env files, You can use a gem like Figaro to load the .env in development.

Reply
Join the discussion
Create an account Log in

Want to stay up-to-date with Ruby on Rails?

Join 86,946+ developers who get early access to new tutorials, screencasts, articles, and more.

    We care about the protection of your data. Read our Privacy Policy.