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. 
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.
Environments
Development
- 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.
Deployment
- 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:
-
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.
-
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.
Production
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.
-
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
SETLOCAL ENABLEEXTENSIONS
SET me=%~n0
SET parent=%~dp0
:: Step 1 – Launch mongod since this needs to be running of course
SET MONGODATA=%TEMP%/dbfolder
SET MONGOPORT=20172
SET MONGOIP=127.0.0.1
echo %me% - Launching Mongo @ IP %MONGOIP% : Port %MONGOPORT% and DataDir @ %MONGODATA%
START %parent%/mongod --nohttpinterface --smallfiles --bind_ip %MONGOIP% --port %MONGOPORT% --dbpath %MONGODATA%
TIMEOUT /t 5 /NOBREAK
::
:: Now launch our node application
::
SET MONGO_URL=mongodb://%MONGOIP%:%MONGOPORT%/mydbname
SET PORT=8080
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://subdomain.domain.com:port/” where subdomain.domain.com 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.
