One Deployment Method for A Meteor Application on Windows


The purpose of this article is to help people successfully deploy a Meteor application to a Windows environment. It appears that there isn’t really a good “definitive” guide to the process – and although this article doesn’t purport to be definitive either, it will give, I hope, enough real world experience to at least let semi-knowledgable Windows people to get something up and running as a start. If I, a total Windows newbie, can get something up and running than anyone can. :slight_smile:

I am hoping, over time, to edit / modify this article to keep adding additional information as we all learn the ins and outs of this.



  • Not much to say here actually, except to deploy to a Windows environment you certainly do not need to develop under Windows. My application is totally written / debugged on Mac OS X and then deployed to a Windows 7 64-bit set of machines. I use git (git-hub to be precise) as the SCCS system – this will make the next step easier. The only key here is to make sure your application actually runs ok. :slight_smile:


  • This part is needed to be done on a Windows machine, and probably the same basic architecture as the end production environment. The reason I setup a separate deployment area is because there are needed here some development tools that one shouldn’t want or need for production. For my own work, I created a Windows 7 64-bit VM that has the following set of tools. Some of these are optional and some are mandatory (at least as far as I can tell):
  • Visual Studio 2012 (?) with C++ and all command line tools installed. Mandatory - Why? Because there is no current way that I know of to bypass compiling / building Fibers / CC each deployment. For that you’ll need the C++ compiler and since it’s going to be run via the command line, the command line build tools need to be installed.

  • Python – Python is needed as part of the building of Fibers. I have V2.7.10 installed but I would think any V2 python could work.

  • demeteorizer - Mandatory. My method has us run demeteorizer on the application to make it “node” neutral

  • git-bash - optional. Since I use “git” for SCCS control, and I’m more comfortable in a *nix command line I use git-bash to do the work to create a production package.

  • node - Mandatory. Use the same version of node as meteor – 0.10.40. I use “nvm” for Windows and this one looks pretty nice NVM For Windows in Go

  • npm – Mandatory. Needed to grab and setup the end resulting node application after we demeteorize our Meteor app.

  • Inno Setup – optional. I use this nice little package to create an install .exe file to make it easy (?) to grab it and then run it on whatever production machine I want. Depending on how you want to deploy this is obviously quite optional.

  • Meteor for Windows - Mandatory. Now this maybe specific to my use case. But I install (and test out) the application on the deployment Windows machine before packaging it up for production. Why? Well, it’s good to confirm the application runs ok on the end architecture – but more so because we’re going to steal two components from the deployment machine that are needed. Well, one for sure – the other maybe depending on how your production environment is going to be run (see below). What two components? Why these:

  1. node - yes, that’s right. We’re going to take the node that meteor runs and grab it to make sure we have the right node version in production. Now, one CAN use nvm (node version manager) to make sure your production environment has the right node, but I find it just as easy, since I’m creating a package anyway, to grab the current node version supported by Meteor with the rest of the app.

  2. mongod - Now, this can be optional if you want to go through and setup a “stock” full mongo deployment on production. For my purposes the only application I was going to run on mongo was my little meteor application, so I figured I might as well bundle that too.


Depending on if you follow my “all-in-one” package idea you may not need anything on the production Windows box except authorization to install a package. However, if this is more complex and you’re going to do more than one Meteor app on the same platform you probably will want to install mongo as a self-starting service and maybe have a common single node binary available too of the right version (0.10.40 currently).

Basic Ideas

Ok, here is the basic set of steps. This will be filled in when I can get to my VM again and go through it step by step myself. So consider these basic place holders to be filled in with more detail. However, these maybe enough to actually get someone going. :slight_smile:

  • Grab your Meteor app from your development environment to your deployment. I use git-bash and simply do a “git pull --rebase” to grab the latest version, but of course you can use whatever method you want to get the Meteor application / project down to the windows machine.

  • Run the application to make sure all dependencies are correct and the project can run successfully.

  • Create a “deploy” folder structure. This will be used to package the application. I have a simple layout that contains two sub-folders:
    C:\deploy\bin – will be used to hold our node and mongod binaries
    C:\deploy\MyApp – Folder that will contain the Meteor application called “MyApp” (change it to whatever your want)

  • demeteorize the application to C:\deploy\MyApp. I use the following git-bash command from the meteor application project folder :
    $ demeteorizer -o c:/deploy/MyApp

Note: Yes, those are forward slashes, but that’s a side effect of git-bash.

  • prepare app for production running :
    $ cd /c/deploy/MyApp/bundle $ (cd programs/server ; npm install)

Now this is where all hell breaks loose for most people. Why? Because the above “npm install” needs to build fibers 1.0.5 that comes from Meteor (NOT the stock fibers build). This is why you need to make sure all the C++ command line builds tools are available and work. You’ll get a some warnings – but – at the end you should have no errors!

You can try to run the actual node application now.
$ node main.js

Note that I do NOT use “npm start”. There is no reason to use this and in production it will be much faster, easier (?) to use run the resultant node program. This is how we’ll start the meteor application in production. Now also note the application will actually NOT run above, but what you should see is, in a second or two, an error message saying three critical environment variables are not set. The point here is not to run the application yet – but to make sure Fibers got built correctly and that the application can run.

FWIW, from git-bash you could do a “export MONGO_URL=xxxx” and “export ROOT_URL=xxx” and be able to run it now if you had a mongod running. Or from the windows command line you could do “set MONGO_URL=” and “set ROOT_URL=” commands (in a .bat file even) to appropriate values. The do the “node main.js” and the application should actually run.

Production Environment Considerations

Ok, now that we know how to get the application ready to run on Windows, how do we actually do it? Well first there are some run-time considerations that need to be made. In general the basic one is, “Are we going to run multiple meteor applications on the same machine?”. If the answer is yes, then it is no surprise that it’s a little more complex to setup, but not horribly so. The other question is, “How efficient does my application need to be?”. Now, generally one would always want the most efficient program right? However, if you aren’t expecting too many users (say less than 30 or so) than maybe you don’t need the added complexity of installing a replication set or front end web application service, the latter I won’t even attempt here.

Simple single application environment

This is the easier environment to setup as it will be self-contained. It maybe also a good place to start and add complexity as you go along and as is needed. The basic idea is to create a .bat or equivalent file and put all the commands needed in it to start everything that is needed to run the meteor application. This involves basically starting mongod, setting the environment variables, and finally running “node main.js”. Here is a sample .cmd file that does exactly this:

`@ECHO off
:: Basic batch file to run a meteor app including mongod
:: Set some common variables
SET me=%~n0
SET parent=%~dp0

:: Step 1 – Launch mongod since this needs to be running of course
echo %me% - Launching Mongo @ IP %MONGOIP% : Port %MONGOPORT% and DataDir @ %MONGODATA%
START %parent%/mongod --nohttpinterface --smallfiles --bind_ip %MONGOIP% --port %MONGOPORT% --dbpath %MONGODATA%
:: Now launch our node application
SET MONGO_URL=mongodb://%MONGOIP%:%MONGOPORT%/mydbname
SET ROOT_URL=http://localhost:%PORT%/
cd …\MyApp\bundle
%parent%/node main.js`

So let’s go over this file and see what it’s doing. First it assumes that the directory structure is how I indicated about, basically a folder with two sub-folders: a “\bin” and a “\MyApp”. The bin folder contains mongod and node from the Meteor development environment (and any needed .DLLs, for example if you want to use Mongo 3.X). It also assumes you are running the .cmd file from the bin folder itself. After setting a few command CMD variables I like to use, we get to the first important part – setting up the MongoDB run-time environment we want. First we set a few variables that control what port MongoDB is going to run on (MONGOPORT and MONGOIP) and also where you want the DB file(s) to be created (MONGODATA). IMPORTANT - This directory must exist prior to run!

Next we actually launch MongoDB (mongod) in a separate execution “window” because we need to launch it and continue the script! Here are the meanings of the command line parameters (in case you want to change them):

  • –nohttpinterface : Do not start up a listener that allows you access via a web page the MongoDB console.
  • –smallfiles : This creates smaller default mongo “page” files, which is good if you don’t except much data as it speeds up initialization. This is bad if you expect a decent amount of data to be stored.
  • –bind_ip : which IP address to listen on
  • –port : which port to listen on
    – dbpath : Path to where the DB file(s) are to be found/created.

Once we launch mongod we wait a few seconds to let it initialize and get ready. Then we get ready to launch the actual meteor application. We set the key environment variables meteor needs:

  • MONGO_URL : URL that gives the location of where mongod is listening. This was just used above so we reuse the same variables. The “mydbname” is the db name you want to use (or is already there).

  • PORT : This is the port # meteor will use. Default is 80. In Development it’s the famous 3000. Can be anything not already in use.

  • ROOT_URL : This is how meteor should expect / use the main URL route. It normally should be something like “HTTP://” where is a valid resolution to your web application and the port should match the PORT variable (and why I actually just use it). Note: HTTP://localhost is probably not what you would want unless you have some pretty special needs (like only local users on the same machine will access it).

Viola! You should now have a running and working application on Windows!

Next Up – More Complex (and more Production like) Multi Application World

Although, from the above you maybe able to figure out the differences one would need to do to the above .cmd file to handle multiple applications but using the same MongoDB service.

How to deploy TO Windows FROM Windows meteor 1.4
How can I start a meteor app WITHOUT building it
Meteor on Windows: runs in dev mode but not compiled

Very handful right now, because Im having this problem :slight_smile: Please, write it complete :slight_smile:


Excellent guide to demeteorize method. I have also had success with this:


I’ll have to give that a go for “self contained” Desktop type applications. I tried Electrometeor - but that didn’t work too consistently and is sort of a part-time hobby exercise by the author it appears, so that other one could be amazing. I wound up writing my own C# / Chromium wrapper to do what I needed, but I’d like a more “production” worthy supported approach.


Electrify is good - the only issue I found is that it is open-source (as in the application code is visible). All
it really does is put all of the dependencies into DLL libraries and then
give you a double-click to run browser shell that contains your app.
Useful, still.

Short list of required dependencies on Windows 10:

  • Visual Studio 2012
  • Demeteorizer
  • Node.js v0.10.40
  • npm v1.4.28 (current)
  • Meteor for Windows

Following the steps above seems to work. I had all kinds of issues as a result of having the wrong version of things above. Thought it was important to point out that having the right version of each (VS and Node.js) is critical. I also had to remove and re-install bcrypt.


The problem I have with electron is that it’s a single user application with Chrome as a front-end and not a real node server. What I would like is to be able to deploy an actual meteor/node.js server app to a windows machine.

There are lots of small businesses that would love a small POS and admin/accounting system with multiple clients. Meteor would be a perfect fit for those markets.

I’ve spent some time researching how to package and deploy to windows with a regular installer, but yet haven’t found any solution that floats my boat.


What about the info I posted above and using a simple packager like Inno Setup? That’s what I do …


Do you have any info on the process for Inno Setup part? Where did you learn how to do that, or was it not in the context of Meteor apps?


It’s a very easy package to use to create install packages. I did learn it actually in the context of a meteor app – but as a self-contained meteor app that also contains the node / mongod and a C#/.NET browser front end based on Chromium. I used Inno Setup to bundle them all “together” (in the folder structure presented above) … with a desktop icon that when clicked launches the C#/.NET – which in turn launches mongo then node main.js to start the Demeteorized meteor app.


To have mongod on my deployment machine, should I install MongoDB or should I “npm install mongo”?

UPDATE: the second option, apparently.


Well actually – there is another option. :slight_smile: On the deployment machine i COPIED mongod.exe (and if mongod v3 a few other files) from the meteor tools deployment binaries that come when you install meteor. And then installed that on the production machine under a /bin directory (that also contained the proper nodejs version)


I’ve just found, “demeteorize -o …” doesn’t work by me. Instead I used “demeteorized -o …”.


Actually the command is “demeteorizer” … and I fixed that. Thanks for the catch!


First time I tried “(cd programs/server ; npm install)” the process crashed because of no python on board. I’ve installed the latest 2.7. I tried again and got a long list of problem which I don’t understand. Could you please give me a clue?

My deployment/production system is Windows Server 2012 R2 x64.

(I rebooted, tried again and got the same result)

P.S. It’s mostly in german there so tell me if you need it in english, I try to do something :smile:


Luckily error messages are almost universal – and I have spent some (nice months) in Munchen so I know a bit of Deutsch. :wink:

In any event, the main issue (I think) is that your are trying the “npm install” running a new version of node (5?) instead of the proper version for meteor which MUST be 0.10.40. So make sure node @ 0.10.40 is in the path first (nvm for windows can help here) and then try the npm install.


OK, it’s tricky for me :slight_smile: Last 3 hours I tried different nvms (the one you linked and 2 more that are listed in the bottom of the pare of the first one) and at last I found a combination that let me demeteorize and compile. I had to install an official node 4.x, demeteorize, then remove official node 4.x, install nvm you linked to and then “npm install”. This way I’ve got no errors, but then: (it says “%1 is not a valid Win32 application”) Have you got another clue? :wink:

I hoped you liked living in Münich :wink:


As for why did I need all this dancing with official node, nvm, nvmw and nodist… well, only in the case of official node could I execute “demeteorizer …”, using the managers I always got “bash: demeteorizer: command not found”.


@rreimche – it is very odd (to say the least) that you need multiple nodes to get the job done. Only node 0.10.40 should be needed for everything. I THINK the issue is that you probably installed demeteorizer under a different node / npm combination (say 4.x) and then switched to node 0.10.40 but did not re-install global demeteorizer again. My thinking is that each version of node/npm has it’s own set of remembered installed modules, so when you switch it switches those too. I would suggest trying the “npm install -g demeteorizer” again when you are running node 0.10.40 and see if that works.

Just to make sure everything is clean – can you try re-demeteorizing and npm install all with just node 0.10.40 and see if the “node main.js” behaves different. The error is familiar somewhere in my mind, but I can’t quite place it but it may be easier to have the environment uniform just in case.


Is this still working for everyone? I can’t get the main page of my app to load when I perform this process despite the same code working either 1. Locally on a Windows machine and 2. On The issue only occurs in the demeteorized version and I am not sure why this is the case.


I actually just tried this a few days ago and it still worked fine. What error messages or anything are you seeing in any log / console output? If it doesn’t run on (that doesn’t use demeteorizer at all) there appears to be some other issue with your application?