title: Unable to load Ruby 2.7.4 (Rails 6) app on AWS Elastic Beanstalk, AL2
body: <p>We have a Rails app that was previously deployed on Ruby 2.6 platform of AWS Elastic Beanstalk. We've had to upgrade to Ruby 2.7.4 as the 2.6 platform was being deprecated by AWS. After the upgrade, we can see that the app is deployed successfully (from the eb-engine.log)... However, when I hit the EB url (XXXXX.YYYYY.us-east-1.elasticbeanstalk.com), nothing shows up. I have verified that both nginx and puma are running and the logs also show that the health check is fine. The environment indicator on the EB console also shows as OK. Any tips on what I need to look for to debug this issue?</p>
  <p>On another note, if I deploy EB's sample rails app first to an env, and then upload my app to that env, it starts to work fine... However I do not want to go to production without first figuring out why I'm unable to access the app by deploying it directly onto a new env. Any help would be much appreciated. Below is my .ebextensions\nginx.config</p>
  <pre><code>files:
    &quot;/etc/nginx/conf.d/010_app_server.conf&quot;:
      mode: &quot;000644&quot;
      owner: root
      group: root
      content: |
        # based on /etc/nginx/conf.d/webapp_healthd.conf
        #
        # and notes from &quot;Getting to Know and Love AWS Elastic Beanstalk Configuration Files (.ebextensions)&quot;
        # (https://medium.com/trisfera/getting-to-know-and-love-aws-elastic-beanstalk-configuration-files-ebextensions-9a4502a26e3c)
        #
        # which suggested taking the approach of including a similar
        # nginx conf file before webapp_healthd.conf, which has the
        # effect of &quot;overriding&quot; the setttings from that file
  
        upstream my_app_new_upstream {
          server unix:///var/run/puma/my_app.sock;
        }
  
        log_format healthd_new_name '$msec&quot;$uri&quot;'
                        '$status&quot;$request_time&quot;$upstream_response_time&quot;'
                        '$http_x_forwarded_for';
  
        server {
          listen 80;
          server_name _ localhost; # need to listen to localhost for worker tier
  
          if ($time_iso8601 ~ &quot;^(\d{4})-(\d{2})-(\d{2})T(\d{2})&quot;) {
            set $year $1;
            set $month $2;
            set $day $3;
            set $hour $4;
          }
  
          access_log /var/log/nginx/access.log main;
          access_log /var/log/nginx/healthd/application.log.$year-$month-$day-$hour healthd_new_name;
  
          client_max_body_size 100m;
  
          set $should_enforce_https 0;
          if ($http_x_forwarded_proto != 'https') {
            set $should_enforce_https 1;
          }
          if ($request_uri ~ ^/pages/health_check$) {
            set $should_enforce_https 0;
          }
          if ($should_enforce_https = 1) {
            return 301 https://$host$request_uri;
          }
  
          location / {
            proxy_pass http://my_app_new_upstream; # match the name of upstream directive which is defined above
            proxy_set_header Host $host;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
          }
  
          location /assets {
            alias /var/app/current/public/assets;
            gzip_static on;
            gzip on;
            expires max;
            add_header Cache-Control public;
          }
  
          location /public {
            alias /var/app/current/public;
            gzip_static on;
            gzip on;
            expires max;
            add_header Cache-Control public;
          }
        }
  
  container_commands:
    010_reload_nginx:
      command: &quot;sudo service nginx reload&quot;
  
  </code></pre>
  <p>And here's my puma config</p>
  <pre><code># Puma can serve each request in a thread from an internal thread pool.
  # The `threads` method setting takes two numbers: a minimum and maximum.
  # Any libraries that use thread pools should be configured to match
  # the maximum value specified for Puma. Default is set to 5 threads for minimum
  # and maximum; this matches the default thread size of Active Record.
  #
  max_threads_count = ENV.fetch(&quot;RAILS_MAX_THREADS&quot;) { 5 }
  min_threads_count = ENV.fetch(&quot;RAILS_MIN_THREADS&quot;) { max_threads_count }
  threads min_threads_count, max_threads_count
  
  # Specifies the `worker_timeout` threshold that Puma will use to wait before
  # terminating a worker in development environments.
  #
  worker_timeout 3600 if ENV.fetch(&quot;RAILS_ENV&quot;, &quot;development&quot;) == &quot;development&quot;
  
  bind &quot;unix:///var/run/puma/my_app.sock&quot;
  pidfile &quot;/var/run/puma/my_app.sock&quot;
  
  # Specifies the `port` that Puma will listen on to receive requests; default is 3000.
  #
  port ENV.fetch(&quot;PORT&quot;) { 3000 }
  
  # Specifies the `environment` that Puma will run in.
  #
  environment ENV.fetch(&quot;RAILS_ENV&quot;) { &quot;development&quot; }
  
  # Specifies the `pidfile` that Puma will use.
  pidfile ENV.fetch(&quot;PIDFILE&quot;) { &quot;tmp/pids/server.pid&quot; }
  
  # Specifies the number of `workers` to boot in clustered mode.
  # Workers are forked web server processes. If using threads and workers together
  # the concurrency of the application would be max `threads` * `workers`.
  # Workers do not work on JRuby or Windows (both of which do not support
  # processes).
  #
  # workers ENV.fetch(&quot;WEB_CONCURRENCY&quot;) { 2 }
  
  # Use the `preload_app!` method when specifying a `workers` number.
  # This directive tells Puma to first boot the application and load code
  # before forking the application. This takes advantage of Copy On Write
  # process behavior so workers use less memory.
  #
  # preload_app!
  
  # Allow puma to be restarted by `rails restart` command.
  plugin :tmp_restart
  
  </code></pre>