Skip to main content

Wrong Ruby version with Postgres user

Ruby • Asked by Jeff See

I'm having a difficult time understanding the postgres section. I've setup a postgres user but when I type "ruby -v" with that user I get 1.9.3, whereas with the deploy user I get 2.1.3 (the correct version). I've checked my passenger setup and it seems to be identical to the one in the video (Using rbenv).

I'm hoping this is the issue that is preventing me from connecting postgres to the server because I've been unable to do so.


So the postgres user I'm talking about is just the database user, not an Ubuntu user named postgres. There is a Ubuntu user with the name of postgres that gets added when you install the database and thats how it restricts permissions to edit the db.

Do you have the error handy for your postgres connection?


Ok that makes more sense - I ended up reinstalling postgres and starting over for that section. However I'm still confused about where to store my production database information - I have manually configured my database information in myapp/shared/config/database.yml with the password hardcoded. I also have it hardcoded in my git repo which I obviously want to remove - do I need my database.yml in my repo at all? If so - why did I have to create one on the server as well?

I don't quite understand how the secrets.yml file works (I'm used to Heroku's dashboard for env variables) Where are they stored? I'm not even sure I'm asking the right questions... either way, I'm up and running but it was a shaky process and I'd like to secure my password obviously.

Thanks Chris.


So the two files database.yml and secrets.yml work similarly. Both files are used to store private information (passwords, API keys, etc). You normally don't want these in your git repo. You can keep examples in the repo so that people can quickly set it up on a new machine, but that's about it.

When you don't have the files in your git repo, that means everyone who clones the repo to their development machine has to create the database.yml and secrets.yml and configure it to point to their database.

Production works the same way. You've got a different database and different passwords / API keys that you need to use there so you create those files manually on the server just like you did on your local machine in development.

If you run your own server and deploy with capistrano, you put these files in a shared directory. The deploy script symlinks this file into the Rails app so that every deploy gets pointed to the correct database and secrets files. No need for environment variables here.

Heroku makes this a bit different than if you do Digital Ocean, AWS, etc. There is no shared directory so you actually set environment variables with heroku config. They overwrite your database.yml and you don't get the same benefits of using secrets.yml since they are already in ENV.

ENV is sometimes tricky to set up when deploying your own app. Apache, Nginx, and all the other web servers configure environment variables differently. That's why they introduced secrets.yml so you don't have to mess with configuring all these different services and your application can simply handle it.

Does that clear things up?


Chris - I'm sorry I didn't get back to you, thanks for your explanation - your information was very helpful, on to my next deployment!


Login or Create An Account to join the conversation.

Subscribe to the newsletter

Join 24,647+ developers who get early access to new screencasts, articles, guides, updates, and more.

    By clicking this button, you agree to the GoRails Terms of Service and Privacy Policy.

    More of a social being? We're also on Twitter and YouTube.