Like @vjau, I've done some manual deployments using that same workflow. To get environment variables in, you can just start the node process with the environment variables already set (either by exporting them individually before issuing node bundle/main.js
) or by cut and pasting something like:
sudo PORT=3000 MONGO_URL=mongodb://user:password@127.0.0.1:27017/mydbname?replicaSet=rs0 MONGO_OPLOG_URL=mongodb://oplogger:oploggerpassword@127.0.0.1:27017/local?authSource=admin ROOT_URL=https://mydomainname.com MAIL_URL="smtp://smtp.mydomainname.com/" node bundle/main.js
Manual deployment got tedious after a while, so I've got one script to run on the client and one on the server to achieve the same thing (build on client - ftp to server - untar - copy/rename folder - restart node).
I've also got that same app deployed to a different server and use a totally different deploy method:
By hacking Julien Chamond's script (from back in the day ...), I've got the deploy process down to a mup-like configuration script and one command on the client ( meteoric deploy
) to have it up and running on the production server a minute or two later. What it's doing behind the scenes is: ssh into prod server - pull the latest app version from github - build on the production server - untar - copy/move folder - restart node. There are downsides to this approach (production server CPU burn; intial setup is fiddly), but it does make the deploy process pretty straightforward, once the initial setup is done. Github repo for deploy scripts here.
For other apps, I've just pinned them to Meteor 1.2.1 so I can keep using mupx
to deploy easily to D.O.. (mupx
hasn't worked consistently for me since 1.2.1).