Hey @nathantreid I’ve made deployments on possibly every platform/service imaginable, including windows servers.
I find windows deployments to be troublesome experiences compared to those on linux/cloud/docker based options.
Here are a few bullet points to keep in mind
- iisnode is too tightly interated with the application and youmight find yourself needing to change the app. Especially wih multi-site deployments, meteor might even be out of question
- I’ve found pm2 to be working great in non-cluster mode and sonewhat unreliable in cluster mode (services hanging etc)
- you need couple pm2 with a service installer like pm2-windows-service or nssm
- stay away from cmd and stay in powershell at all times
- either run everyhing with admin privileges or do it selectively with global installs (pm2 an npm in this case) but keep track of your privileges and your global node modules folder
- backup your global node and npm installation’s paths because they tend to change every now and the across node/npm upgrades
- npm binary deps tend to be hard to ger or build, you will need proper windows set up of npm and some windows build tools
- having meteor installed on the target, although unconventinal, might help
- your experience might be highly inconsistent across diferent machines due to some windows library missing/existing because of some other software or some versions or windows upgrades messing with how things behave
- try to manage your environment variables with pm2 as well, I’ve tries a few different things and on2 seemed to be easier for this as well
- you can set port to 80 on pm2 or front your pm2 service with iis, apache or nginx to do a simple reverse proxy. I’ve found nginx to be the leanest
- if you also want to host mongodb on the same windows machine make sure you read mongo windows release notes for your version. for some reason I’ve found the old mmapv1 engine to work much more stable as opposed to wiredtiger
- starting mongodb, pm2 and iis/apache/nginx in the right order might not be fully possible or when it is it is delayed for too long therefore you will have to live with some wait time or false positive log entries in one of these pieces oh and pn2 is also good with separating out the logs into a dedicated directory and rolling them for you.
I’m sure there are other things I forgot to mention but I’d say have a virtual windows machine image handy, take snapshots along the way. In fact I’ve found it especially hard to “undo” things in windows so having a virtual production windows helps a lot by taking snapshots of successfull deployments/upgrades so that you can revert easily if need be.