AWS Elastic Beanstalk environment variables overriding at the EB application level

Question

I am currently running the same NodeJS Sails app on two different "environments" within the same Elastic Beanstalk "application" (AWS-specific terms in quotes). My intention was for these "environments" to serve as staging and production. Sails provides a built-in method for swapping configs based on the environment variable NODE_ENV . However, when I set the environment variable in one "environment," it overrides the value for the other.

I have tried using the AWS CLI command eb setenv NODE_ENV="environment_name" as well as using the web interface. (The setting in question is at Application > Environment > Configuration > Software Configuration under the "Environment Properties" header.)

I have been trying to search for this issue, but I have been having a hard time finding anything that addresses it specifically. Answers like the selected one here imply that it is possible to do what I am looking for.

Is there something wrong with the way I am setting this variable? Am I misunderstanding how Elastic Beanstalk handles these settings? I understand that I can also set environment variables by changing the .ebextensions file for different deploys, but I would prefer a cleaner fix.

As requested, here is the output from eb status and eb list (actual application name replaced):

$ eb status
  Environment details for: app-staging
  Application name: app
  Region: us-east-1
  Deployed Version: 1.1.0
  Environment ID: e-fxxxxxxxxx
  Platform: 64bit Amazon Linux 2015.03 v2.0.1 running Node.js
  Tier: WebServer-Standard
  CNAME: app-staging.elasticbeanstalk.com
  Updated: 2015-12-08 03:54:37.894000+00:00
  Status: Ready
  Health: Green

$ eb list
app-production
* app-staging

Answer 1

It turns out this issue was happening because the AWS web interface was not keeping up with the changes I was making. The environment variables were not being overridden. Logging out and back in fixed this for me.

I have noticed that, in general, many perceived issues on AWS may be fixed in this way.