Never use --production flag to deploy!


I noticed a new message in the logs of one of my applications

Warning: The --production flag should only be used to simulate production
bundling for testing purposes. Use meteor build to create a bundle for
production deployment. See:

When you check the corresponding page it says to never use --production flag to deploy but doesn’t offer any viable alternative for Windows.

–production flag is purely meant to simulate production minification, but does almost nothing else. This still watches source code files, exchanges data with package server and does a lot more than just running the app, leading to unnecessary computing resource wasting and security issues. Please don’t use --production flag to deploy!

The options the guide explore are

  • Galaxy : doesn’t work on premises
  • Meteor UP : doesn’t work on Windows
  • Custom deployment : requires you to install an MSVC toolchain due to node-gyp

Not everyone has the authorization to install an MSVC toolchain on a server - if I could do what I wanted, I would have already installed a Linux server. So basically this warning is useless as it doesn’t provide me with any viable alternative. Nor does it tell me where to find more information about the security issues it warns me about and how to disable the corresponding code manually.

At the end, I am exactly at the same point after the warning : I deploy with --production because there is no better way to do it !


So you want to “deploy” your app by just running meteor --production?

I think the issue with this is that even though you’ve flagged production, you’re still running the whole development environment on top. Your server and the app are not going to run efficiently (I don’t know if this is true, never done it, just assuming) if you don’t actually bundle and deploy it properly.

Not sure what the answer is for windows though. I develop on Mac and deploy to NodeChef which is heaps cheaper than Galaxy and includes Mongo hosting, does free SSL (letsencrypt) and heaps more…


If deploying to Scalingo is an option, it couldn’t be simpler. You just set it up as another Git remote and push your changes in the same way you do to Github or Bitbucket. Scalingo do the build on their server.


You can setup a build server running Windows to compile the app before pushing (this is pretty simple with any CI agent - we’ve had success using buildkite and bamboo in the past)

To run the app, I’d recommend using IISNode which handles process management, URL rewriting, logging, etc. (we have an example config here)