Meteor built-in node/mongo vs. os depended versions to use for production


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?

Thanks for your comments and help.


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.


Hi @arunoda how do you power your environments for kadira? Do you use the MDG patched binaries for node and mongo? What do MDG run on galaxy?

Looking forward to some hints from MDG or community.


For meteor apps we are simply using mupx and it uses Meteor’s forked mongodb driver (automatically) and Node v10.x

There is nothing magical we do here in this space.


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?


No it’s for production as well. It’s a version where binary modules has been removed.
I think @glasser can confirm that.


What do you mean when writing:

Do you mean this is a different build of their node and mongo packages for production?

Where are those located? Do you mean the binaries located in

.meteor/packages/meteor-tool/1.1.8/mt.os-linux.x86_64/dev_bundle/bin and .../mongodb ?

From my knowledge, this versions are build by scripts/build-(mongo|node)-for-dev-bundle


Ah not the dev bundle.
I was referring to this one:

This is a forked version of mongo driver. Seems like you are talking about the mongod comes with Meteor dev bundle.

Oh! then I haven’t play much with them.


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:

git clone --branch "v0.10.40-with-npm-5821" --depth 1


git clone --branch "ssl-r2.6.7" --depth 1

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.


Hi David ( @glasser )

really thanks for your quick and clear response.

So it is not recommend to use the builds of node and mongo from your “patched” versions


if someone use them in his production environment, it wouldn’t be a fault and it could be used in production as well?

Sorry for my lazy questions about that.