How does a Rails app set its Environment (Dev., Staging, etc.)?

Question

Having a very confusing issue

My local app is running in its staging environment. I use puma-dev for the server and when I tail it by running tail -f ~/Library/Logs/puma-dev.log it says that the environment is development, but when I log out to my view using <%= Rails.env %> it says staging and the app tries to use any staging environment variables that it needs instead of the variables for the development environment.

The app has environments for Development, Staging, Test and Production. It is only recently that I noticed this was running in staging, I'm not exactly sure how or when it switched over but for the last couple years it was running in dev just fine, I recently added a staging env to help with a rails upgrade and some point over the last week this started running in staging.

I always thought this was set by the server when started but with puma-dev saying its env is development. I am at a loss for how this is trying to run in staging.

puma-dev output when starting:

io[19626]: Puma starting in single mode...
io[19626]: * Version 4.3.5 (ruby 2.4.6-p354), codename: Mysterious Traveller
io[19626]: * Min threads: 0, max threads: 5
io[19626]: * Environment: development

Can anyone shed some light on exactly where or how a Rails app decides to set its Environment because for the life of me, I cannot find it in the app.

As a test based on the answer below (which was useful) I log out these 3 variables:

1. <%= Rails.env %> which ends up being staging
2. <%= ENV["RAILS_ENV"] %> which ends up showing nothing
3. <%= ENV["RACK_ENV"] %> which ends up being development

Also, if I run the rails console and type in Rails.env is also returns 'development'.

I also used the suggestion in the answer below and ran RAILS_ENV=development rails server. When doing that, both ENV["RAILS_ENV"] and ENV["RACK_ENV"] were set to development but the application was still running in staging (so the first variable above didn't change but the second one did).

The app is still trying to use all the staging ENV variables that are set (S3, etc.). For this app I also recently updated from Rails 3.* to 4.2 (I know these versions are old. I inherited the apps and am working on it). Which was the reason for adding the staging Environment. I was unable to find anything in the upgrade guides that talks about this kind of issue so I, at first, didn't suspect it was related but I wanted to give as much info as I could on this issue.

Answer 1

To make sure I'm clear:

• your local app is 'staging'
• you want your local app to be run in 'development'
• you see puma running in 'development', but the app seems to be pulling variables for 'staging'
• you want puma running in 'development' and the app to recognize that it's in 'development'

Puma is setting its environment like this:

:environment => -> { ENV['RACK_ENV'] || "development" }

Rails sets .env like this:

# File railties/lib/rails.rb, line 73
def env
  @_env ||= ActiveSupport::StringInquirer.new(ENV["RAILS_ENV"].presence || ENV["RACK_ENV"].presence || "development")
end

So if RACK_ENV is development, but RAILS_ENV is staging, then they will mis-match.

Try:

RAILS_ENV=development rails server

Or, check the values of ENV["RAILS_ENV"] and ENV["RACK_ENV"] while server is running.

Answer 2

Finally figured it out today.

Since adding the staging environment to the application I guess I needed to add some config files inside a puma directory in the app itself to help puma figure out what it needed to do.

To be honest I'm still not sure why I needed this since puma would say it was running in development, which I thought was setting the environment.

What I did was add a puma directory inside the config directory and then I added a file named development.rb and in there put the setting for running in the development environment.

Content of puma/development.rb:

#!/usr/bin/env puma
root = "/Path/to/the/application"
daemonize false
environment "development"
directory root
pidfile "#{root}/tmp/pids/puma.pid"
stdout_redirect "#{root}/log/puma_stdout.log", "#{root}/log/puma_stderr.log", true
workers 2
threads 8,32
bind "unix:///#{root}/tmp/sockets/puma.sock"
bind "tcp://0.0.0.0:8080"
preload_app! 

It nows runs as expected on my local machine.