Using node-foreman under supervisord in production

I got so comfortable using foreman with Rails applications on Heroku and elsewhere that I seek out clones when I work with other languages; I use honcho for Python/Django and I've been using node-foreman to develop an Express project. I'm ready to move that Express project into production (Ubuntu 14.04 on Amazon EC2) and am having troubles.

I can launch and run the project using nf start just fine, but the node-foreman docs say not to daemonize such a thing, but rather that I should generate a supervisord conf file using something like

nf export --type supervisord --user ubuntu

This works, and the results look correct, but the Express application won't launch as it seems unable to pick up the values from the environment values. supervisord is successfully running a Django-based RESTful API server on the same host. Sensitive values replaced, foreman-web-1.conf looks like:

[program:foreman-web-1]
command=npm start
autostart=true
autorestart=true
stopsignal=QUIT
stdout_logfile=/var/log/foreman-web-1.stdout.log
stderr_logfile=/var/log/foreman-web-1.stderr.log
user=ubuntu
directory=/home/sites/site-root
environment=PORT="3000",API_HOST="api.example.com",USER="user",PASS="password",SES_USER="ses_user",SES_PASS="ses_pass",SES_SMTP_HOST="email-smtp.us-west-2.amazonaws.com",SES_SMTP_PORT="587",RECAPTCHA_SITE_KEY="site_key",RECAPTCHA_SECRET="secret",FEEDBACK="someone@example.com",PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games",PORT="3000",FOREMAN_WORKER_NAME="web.1"

but the stderr.log contains

/home/sites/site-root/node_modules/express-recaptcha/lib/express-recaptcha.js:27
  if (!this.site_key) throw new Error('site_key is required');
                            ^
Error: site_key is required

which indicates that the RECAPTCHA_ environment variables aren't being seen.

I can't figure out if the problem is with supervisord or my Express application or with node-foreman and I'd appreciate any insights or recommendations. I suspect it's something simple and obvious, but this is the first time I've tried to get all these pieces working together in a production environment.

Apparently it takes a lot of work to let supervisord know you're serious about changing settings. This serverfault answer helped me see the light.