Hi during preparation of our meteor arm universal fork, I come to the question what node and mongo version should be used when running your app in production.
In case that during development meteor brings it’s own node and mongo with it, what software should be used in production when you had run “meteor build”?
What do you do? We are currently running our meteor apps on Ubuntu 14.04 LTS servers with system wide installed node and mongo releases.
Q: Is this the advised procedure or should anybody use the binaries from meteor environment also in production?
I did also encounter another occurrence of this issue with meteor-spk (issue here) which basically packaged my meteor applications for the Sandstorm platform with an incompatible nodejs version. If I remember correctly the velocity team did also face this problem when they wanted to start mirrors of the application to run tests.
I think there should be a canonical way to (1) get the {node,mongodb} binary used by meteor and (2) get the associated meta-data such as the release number.
Since today I got all special repros from MDG for node, npm, mongo and mongod compiled also on armv7l architecture. So also on that architecture meteor apps may run in production with their specialized executables.
So does this mean, that the forked versions of node and mongo are only necessary during development but not production? May we get an “official” statement for that?
Ok, this one (mongo driver) is just an “optimized” one? Where do you add it? Global via npm -g install or do you install this beneath the apps build folder where you start your app via node main.js?
But, what I was originally reflecting to this two repos, which are in use by the build-... scripts:
I am not sure how MDG would like “us” to proceed. In case that they deliver specialized binaries with all their releases and check that their tests run with those binaries, wouldn’t it be recommended and a consequence that also the production environment should at least run with those binaries?
In general we don’t expect people to be running forks of Node in production; if that were expected then we’d be much louder about that in the docs, generated bundle README file, etc. Right now we fork Node to apply this PR (which is in Node 0.12 but won’t be in 0.10), which only affects npm as run by the CLI tool and isn’t particularly needed in production.
Our fork of Mongo just turns on SSL support, which at least in the past wasn’t in the main downloadable binaries. If you need SSL support, it’s likely that your provider or your OS’s packaging system already enables it.