"meteor run --production" with MONGO_URL vs. bundling

Question

Perhaps my question is a duplicate of this but I feel it adds some specifics that make it differ somewhat.

I currently have a Meteor Docker setup, based on the node:0.10 image, that first bundles the app and runs "node main.js" as its CMD. The image also installs Meteor and uses its command to bootstrap the environment and install necessary packages.

It occurs to me that the image would be vastly simplified if, instead of using node:0.10, I could use a more minimal Linux image and simply install curl/git/meteor. Removing the build step would further simplify things, since based on my understanding "meteor build" has no means to not build mobile apps if they're configured but not needed (I.e. if I normally build Android/IOS apps, I can't easily not build them if I just want a bundle). Further, my development environment already uses MONGO_URL and a containerized MongoDB instance, so I'm not even using a local database when developing.

So, what is the difference between "meteor run --production" with a set MONGO_URL, and "node main.js"? What happens in one instance that doesn't in the other?

In particular, does "meteor run --production" detect the presence of MONGO_URL and not spin up a separate, unused mongod? I clearly see data in the database pointed to by MONGO_URL but I'm not sure if the meteor command spins up a separate one that sits around and wastes CPU cycles/RAM. Based on the previous question, I gather it still polls the filesystem for changes. But does this just use inotify under Linux, and am I correct in assuming that's a fairly minor performance hit?

I imagine that, if I needed every ounce of performance out of my servers, bundling is the way to go. But if running "meteor run --production" with MONGO_URL set only incurs a minor performance hit while vastly simplifying my setup, it's probably worth it to me to simplify my Dockerfiles and unify my dev/production setup a bit more closely.

Thanks.

Answer 1

A point to note is that meteor run --production ... means "run in an development environment that simulates production" and not "this is how you should run your app in production".

So process.env.NODE_ENV is set to development when you run above command.

https://github.com/meteor/meteor/issues/180#issuecomment-30043150

Answer 2

Any meteor command does use the database specified by MONGO_URL, and that database alone. I routinely point MONGO_URL to a blank string when running meteor test-packages to avoid the overhead of spinning up a Mongo instance if the package doesn't do anything database-related. For peace of mind, you can double check that by running htop in another terminal and seeing that no mongo processes are created.

Regarding meteor run --production monitoring the filesystem for changes, yes, that's a minor CPU overhead. Again htop can help.

"meteor build" has no means to not build mobile apps if they're configured but not needed (I.e. if I normally build Android/IOS apps, I can't easily not build them if I just want a bundle)

In a pre-build step, you can easily replace .meteor/platforms to say just server\nbrowser (remove the android and ios lines) if you don't need the mobile platforms.

An advantage to bundling then running node main.js is that you can use pm2 (a better alternative to forever) to keep your application running instead of crashes. However, see also Meteor Up.