As a newb to Meteor, I have already started quickly and easily building an app. The platform is amazingly straightfoward to develop in - I’m loving it!
However, I’m still new to the node world and as I’m reading ahead (for when it’s time to deploy to production) it seems like there are many additional considerations when deploying a meteor app, as opposed to the “more traditional” platforms I’ve used in the past.
A few questions: Why does a thing like “demeteorize” need to exist, isn’t a meteor app just a node app? Why are so many services needed to deploy and host your app (i.e. modulus + compose.io + x, digitalocean + AWS + compose)? Wouldn’t it be slow to serve your data and your code via different service providers?
I’m thinking this is all related to scaling and performance, but for a newbie it’s quite overwhelming and makes me nervous about spending a bunch of time building a killer app only to have a hundred question marks when I’m ready to deploy it (how much will it cost to host, how hard will it be to setup, how much time will it take to prepare it for deployment, etc.)
And finally, is there an intro guide somewhere that I missed which covers all this stuff?
I have to admit deploying a Meteor app is a pretty daunting task. For someone doing it for the first time it sure feels like you have to sacrifice a goat and a ram to get it working. The tutorials are all over the place on this so that adds to the confusion.
The least painful way I’ve found is Meteor Up (MUP) and even then it takes quite a bit of trial and error to get both the server and the MUP script configured right. The good news is that once you have it working, redeploying is a breeze ($ mup deploy).
Don’t worry, it’s not super difficult. A node newbie like me managed to deploy without mup or demeteorize, although these tools probably make deploying a whole lot easier. A lot of tutorials are out of date though I found. I’ve been working on a deployment tool for RHEL/CentOS that I’ve been using myself, I’ll release it soon and maybe some people like yourself may find it useful.
Thanks everyone for the replies. I will read through the resources you all have listed and experiment with them.
I guess what I still don’t understand though, is what is the nature of the differences between Meteor and other node apps that make them more difficult to deploy? I.e. why do they need to be demeteorized? And if goat sacrifices are necessary, just how many goats and must they be of a particular size?
In your case hellstad, you said you were able to deploy without demeteorizing, why did you choose to do that and how? (maybe a brief thought if you have time… of course I would like to read your guide whenever you release it).
I realize I can try to just follow along a set of instructions but without knowing the nature of what makes the challenges unique I’m not sure if I’ll be able to attain a “solid” understanding of what I’m doing. Thanks again for your insight
I have used this (on Digital Ocean (but suspect it is generic enough to be applied to many other hosting situations). There’s a lot of setup to do in this one. But that’s all a one-off. Redeploy is simple.
@agentfitz demeteorizer makes a package.json so you don’t have to delete/reinstall dependencies on different architectures. I just use meteor build (like I believe mup does as well) because it’s not that different, you just need to reinstall compiled things like fibers. Then it works as a regular node app - you can run it using node, forever, pm2, etc.
I’d +1 that deployment is pretty hard if you’ve never managed your own servers before … its tough to figure out where to begin. I think Modulus is the only straightforward option. I’m looking forward to trying MUP/Cluster though.
I recommend either Arunoda Meteor Deployments , or Modulus.
I recently switched from mup + linode (which worked well enough) to Modulus. I’m hosting both the app and the database on Modulus, and it’s been easy and smooth so far. Their support team has been helpful and responsive.
Excellent question. This is the reason we introduced an entire chapter on these things for our Meteor in Action book. As I wrote it to give a good overview for your deployment options I can recommend it as a starting point. But overall, I feel that deployment is hard with any tech stack. Even with LAMP you should be familiar with the components e.g. managing SSL certs, or buy everything from a service provider. But that you can have from folks like modulus.io as well.
Honestly, i am still hoping that meteor build will soon be capable of doing what demetorizer does as it is indeed confusing why it is not producing a vanilla Node.js app in the first place.
Demeteorising takes all the code and builds it in a way that it can run straight on Node on pretty much any server, but the code is a lot less user friendly in this format and it is designed for production only.
The way I look at it is that Meteor makes things amazingly easy to develop, a lot of common tools people use (build tools, command line interface, etc) all come with ‘Meteor’ and when you want to just run a plain old Node application you need to ‘export’ your code to that format.
It’s actually not necessary to use multiple services, it’s just necessary if you want all the fancy auto-scaling and such like that. You can totally deploy a meteor app to its own vps with its own, local mongodb instance.
Modulus is good because it’s a really convenient way to deploy a meteor app. You can use a modulus db behind your app if you want. People use compose.io because it’s pretty kick-ass for a deployed db. I use a sandbox db at mongolabs because nothing I’ve built needs what compose.io offers (maybe one day!).
There are a number of guides, but they offer differing information because the meteor world is moving really fast right now. It’s definitely frustrating if you’re just jumping in.
I’m pretty new to all of this as well. I spent one long, frustrating evening just trying to deploy a single app to Digital Ocean. Most of my time was spent learning that MUP requires the correct version of node.js (0.10.x, not 12) and how configuration for nginx works. But that one frustrating evening was really all it took to get to where I feel like I know what I’m doing.
What helped me the most was learning about configuring nginx to use node.js in the back. I found a guide that explained that outside of the context of meteor (sorry, I don’t remember which) and once I understood what nginx was doing and how to configure it, it all made a lot more sense.
@RevMen That node version is a massive gotcha. I didn’t take notice at all the first time I installed since the latest version was 0.10.36 or something like that, then not long ago I didn’t realise my script installed 0.12 and spent hours trying to figure out why my app wasn’t starting!