Right now, we have only tested running the meteor command line tool in development mode, because this seemed like the biggest pain point for people.
When you bundle your Meteor app for production using meteor build, you end up with a pretty much standard Node.js app, that would probably run anywhere including Windows. See here: http://docs.meteor.com/#/full/deploying
I’ve been using Windows for development and did my first deployment today without any issues. As far as I know you just can’t use mup yet? I also have a Mac on KVM so tonights journey towards deployment will be with mup on the Mac.
I didn’t find this in the docs but on some forum … if you start your application like this:
meteor run --production
then the build process will actually minify the source, my browser now loads 100KB for my application instead of 2MB.
And then I made a Windows Service that is running meteor for me.
I’m going to walk back what I previously posted. I’m trying to deploy my Windows build to CentOs right now and hitting quite a few issues. bcrypt was bad so I had to load the repo onto a linux box, build the package there and now i’m still having a couple issues i havne’t figured out yet.
Just to prevent any confusion, --production isn’t actually meant for production mode. It simulates production mode by minifying and concatenate the source files.
From what I read on SO regarding the particular error I was getting. I’ll have to go back and try to find the thread. The SO thread was referencing another Node app but the issue seemed to be identical. When I went into bundle/programs/server and rand npm install bcrypt the issue was resolved.
EDIT: I need more sleep…this was what led me to try to overwrite bcrypt which worked. It’s about compiling on OSX which I wasn’t, I was on Win8.1 but I figured why not give it a shot and sure enough it solved the issue.
On some random blog post from early 2014 I read that some people were adding that node module to their gitignore file and just manually installing the module on deployment.
That was the easy issue I hit!
I have the latest Windows version of meteor, and was deploying onto CentOS 6.6. I know that’s behind a bit but that’s what I got for this.
Well or not. I tried doing a meteor build on my Mac OS X and deploying it to a Windows 7. So far no love … After fixing the node.js version issue (you know the README says node 0.10.36 or later, well that is NOT true … 0.12.xx doesn’t work at all … ) … I am getting a module not found “websocket-direct” ? (something like that) … No idea how to fix this.
I also noticed that in the standard Meteor build … there is no “windows” architecture available … only Mac and Linux flavors… is that the problem?
I have a giant need to be able to develop on Mac and deploy on Windows (see my separate thread on this) …
Steven, you can not build on one machine and move a build to your Windows server. With meteor you can do ‘meteor deploy’ which will build and deploy to a server hosted by meteor.com. If you want to host on your own server you can use Meteor Up (mup). Meteor Up does not support Windows, it supports only Debian/Ubuntu flavours and Open Solaris.
So what am I doing? I develop on my Mac computer. I’ve installed Meteor on my Windows server. I then move the source files to the Windows server and start the app there. Yes, it’s running in “development” mode but that’s not an issue for my application. If running with ‘meteor run --production’ the source files are minified.
The meteor application should always be running and it should be able to start and stop it in a controlled way, therefor I made a Windows Service (running as Local System account).
In the Windows Service a thread pool worker thread is started. There I start a System.Diagnostics.Process (a window-less local process, acting like a cmd-console) and the application I start in that process is a .bat-file containing ‘meteor run --production’. All output from the process (what meteor will write to server-side console) will be piped to a file (to a rolling file using log4net).
Magnus – that sounds almost perfect for me as well. I was hoping to just make a “meteor build” and take the resultant tar file over… But you solution sounds just perfect too. I am in no way a Windows guy at all Can I take a look at the .bat file ? I like the idea of the log4net rolling logger for output … is that a separate program you wrote (one presumes in C# .net?)
It works like this:
Think of the Windows Service application as a console window, but without a window. And everything that should be displayed in that window is instead written to a file. The commands you write in the .bat-file is the commands that you want to execute in that console. Yes, it’s a C# .net program I wrote and log4net is a .net library/package from Apache. Let me know if I can help you in any way.
Is it a problem if Meteor is installed to one user account (the old “Why does it have to be under AppData of one user?” story), and I want my app later on to be run by a different account?
I am having a similar issue – I want to deploy my app like a windows.exe … at least as far as the user is concerned … and to 1000+ windows machines … each independent. I really would rather not figure out a way to also bundle node.js AND MongoDB … as it runs just fine with the “build-in” node.js and mongo via the “meteor --production” style. However, the start up time IS rather slow … is there a way to have the best of both worlds?