rails: Rails 5 - Puma default port does not take effect

This works for me

$ env PORT=4000 rails server
=> Booting Puma
=> Rails 5.0.0.beta3 application starting in development on http://localhost:4000
=> Run `rails server -h` for more startup options
=> Ctrl-C to shutdown server
/Users/richardschneeman/Documents/projects/codetriage/config/initializers/git_hub_bub.rb:2: warning: already initialized constant GitHubBub::Request::USER_AGENT
/Users/richardschneeman/.gem/ruby/2.3.0/gems/git_hub_bub-0.0.6/lib/git_hub_bub/request.rb:7: warning: previous definition of USER_AGENT was here
/Users/richardschneeman/Documents/projects/codetriage/config/initializers/git_hub_bub.rb:3: warning: already initialized constant GitHubBub::Request::RETRIES
/Users/richardschneeman/.gem/ruby/2.3.0/gems/git_hub_bub-0.0.6/lib/git_hub_bub/request.rb:12: warning: previous definition of RETRIES was here
/Users/richardschneeman/Documents/projects/codetriage/config/initializers/git_hub_bub.rb:4: warning: already initialized constant GitHubBub::Request::GITHUB_VERSION
/Users/richardschneeman/.gem/ruby/2.3.0/gems/git_hub_bub-0.0.6/lib/git_hub_bub/request.rb:8: warning: previous definition of GITHUB_VERSION was here
[59980] Puma starting in cluster mode...
[59980] * Version 3.0.0.rc1 (ruby 2.3.0-p0), codename: Schneems Sleak Shoes
[59980] * Min threads: 5, max threads: 5
[59980] * Environment: development
[59980] * Process workers: 2
[59980] * Preloading application
[59980] * Listening on tcp://localhost:4000
[59980] Use Ctrl-C to stop
[59980] - Worker 0 (pid: 60018) booted, phase: 0
[59980] - Worker 1 (pid: 60019) booted, phase: 0

Are you using Puma 3.0 or above?

This still isn’t fixed yet? In Rails 5.0.1, I have this exact behaviour.

Just for the records: using the following code (in config/boot.rb), the port can be changed for the app.

# Change default port of development server, see http://stackoverflow.com/questions/18103316
require 'rails/commands/server'
module DefaultOptions
  def default_options
    super.merge!(Port: 3001)
  end
end
Rails::Server.send(:prepend, DefaultOptions)

This was fixed with Puma v3.7.1, please upgrade!!

When using puma -p 4000, the server still starts with the default port 3000. rails s -p 4000 doesn’t work either.

These are a issue of Puma. Ref: https://github.com/puma/puma/issues/1200

Actually I can set the port via PORT environment variable, but it fails it I use rails s -p 3001.

rails s -p 3001
=> Booting Puma
=> Rails 5.0.1 application starting in development on http://localhost:3001
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.7.0 (ruby 2.3.3-p222), codename: Snowy Sagebrush
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://0.0.0.0:3000

PORT=3001 rails s
=> Booting Puma
=> Rails 5.0.1 application starting in development on http://localhost:3001
=> Run `rails server -h` for more startup options
Puma starting in single mode...
* Version 3.7.0 (ruby 2.3.3-p222), codename: Snowy Sagebrush
* Min threads: 5, max threads: 5
* Environment: development
* Listening on tcp://0.0.0.0:3001

Wow. This is going deeper than I thought.

@prathamesh-sonpatki that will not work. config/puma.rb will blow away on the rack config option.

➜  puma-demo b rails s -c config/puma.rb
=> Booting Puma
=> Rails 5.0.0.beta3 application starting in development on http://localhost:3000
=> Run `rails server -h` for more startup options
Exiting
/Users/sward/work/experiments/puma-demo/config/puma.rb:8:in `<top (required)>': undefined method `threads' for main:Object (NoMethodError)
    from /Users/sward/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/rack-2.0.0.alpha/lib/rack/builder.rb:42:in `require'
    from /Users/sward/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/rack-2.0.0.alpha/lib/rack/builder.rb:42:in `parse_file'
    from /Users/sward/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/rack-2.0.0.alpha/lib/rack/server.rb:318:in `build_app_and_options_from_config'
    from /Users/sward/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/rack-2.0.0.alpha/lib/rack/server.rb:218:in `app'
    from /Users/sward/work/rails/railties/lib/rails/commands/server.rb:59:in `app'
    from /Users/sward/.rbenv/versions/2.2.2/lib/ruby/gems/2.2.0/gems/rack-2.0.0.alpha/lib/rack/server.rb:353:in `wrapped_app'
    from /Users/sward/work/rails/railties/lib/rails/commands/server.rb:124:in `log_to_stdout'
    from /Users/sward/work/rails/railties/lib/rails/commands/server.rb:77:in `start'
    from /Users/sward/work/rails/railties/lib/rails/commands/commands_tasks.rb:90:in `block in server'
    from /Users/sward/work/rails/railties/lib/rails/commands/commands_tasks.rb:85:in `tap'
    from /Users/sward/work/rails/railties/lib/rails/commands/commands_tasks.rb:85:in `server'
    from /Users/sward/work/rails/railties/lib/rails/commands/commands_tasks.rb:49:in `run_command!'
    from /Users/sward/work/rails/railties/lib/rails/commands.rb:18:in `<top (required)>'
    from bin/rails:4:in `require'
    from bin/rails:4:in `<main>'

Hence I mentioned we need to parse the config/puma.rb if present and actually pass port to puma via rack option, which is what I had worked on to support.

Again, we need to consider if we need to treat puma as a special case. Either way just passing puma config via -c is a bad option as that will have side effects on rack.