Reading this thread, I see alternatives to MUPX discussed for deploying Meteor. From @smeijer:
Deploying meteor really ain’t that hard. meteor build, and deploy as any other nodejs app.
why not use pm2-meteor
What are the benefits of Meteor Build vs. pm2-meteor for deploying large projects?
All deploy methods basically use the same principal:
meteor bundle command)forever and upstart
pm2
You can do all this manually every time, or have a tool do the heavy lifting for you.
Any deploy-tool can suddenly stop being maintained, just look at mup, mupx, … If you depend too much on that tool, you might get stuck.
I’m using pm2-meteor at the moment, because it’s only a thin wrapper around pm2. If pm2-meteor should break for some reason in the future, I can always upload my bundle manually, and feed it to pm2
Or you can write a small shell script which does all that for you.
I mean, my deployment process looks like this:
git pull, meteor build, then move the tarball over to the correct directory, untar, npm install and then forever stop / forever run.
That’s nothing which cannot be easily automated, no external scripts needed.
I use ansible to manage our meteor servers, load balanced with tengine (nginx fork), as well as a 3 server mongodb cluster.
This turned out to be a great solution so far.
The problem starts when your host (dev) machine has a different OS then your target (server) machine. I, for one, run macOS on my dev machine, but my servers are on Linux obviously. Which poses problems with binary npm modules and requires you to rebuild them. That’s only one issue which is normally handled by a good build tool.
I’m not seeing why a shell script cannot handle this case as well - you shouldn’t need to craft the commands by hand.
As long as you installed all dependencies the default case is this:
./configure
make && make install
Of course that’s doable, but you need to know that is an issue in the first place. And you need to know how to write shell scripts. And then you need to be on top of the current developments so your shell script doesn’t break on new Meteor versions 
. While that is still not rocket science, I assume for many people that’s something they would like not to dive into.
For me mup was one of the things which made want to work with Meteor. Ease of development AND ease of deployment - that’s something other platforms didn’t give me before.
I’m not sure why new meteor versions should break anything - the commands to rebuild stayed pretty much the same over the years.
And writing a simple shell script really isn’t rocket science.
Also: It’s not a good idea to develop on two different kinds of OS and expect to never have to test anything on a production-like system for issues.
That’s why professionals have (at least) three systems: Development, Production and Staging
Meteor 1.4 broke mup because directory structure for the npm modules changed.
And my own shell script survived. Funny
Then again, I don’t include node_modules in my repo or copy that over at any time.
Well good for you . But my case still stands - deployment with Meteor is non-trivial, you can’t expect someone who is new to the platform to immediately know everything that’s required to know all this stuff, that’s why I still think there is a market for deploy tools like mup.
I’m of the opposite opinion: An over-reliance on such external tools only leads to problems when they’re not maintained anymore.
I have no problem with using such things - but only if you know how to do without them.
What are the biggest benefits of tengine over nginx in your experience, especially with Meteor?
I totally agree with you. Of course, I could delve into the details on how to deploy a Meteor app directly, using shell scripts. But also for me, it was one of the goodies of Meteor that I just don’t have to care about all of this. mup(x) not only deployed the app for me, it also put it into a docker container and assured the installation was running correctly. Without mup(x), Meteor has just become a bit harder to work with. And this journey seems to continue. One of the most prominent USPs of Meteor was its simplicity, from development to deployment. And a lot of this charm has already been lost. Today, I only hear statements like “Well, why don’t you learn DevOps?”. (And please, don’t refer me to Galaxy. That’s way too expensive for my needs.)
One of the most important would be the sticky sessions module. This way you fork as many Meteor processes you wish (preferably and reliably with pm2), and load balance them with Tengine. The sticky sessions module ensures the user doesn’t get disconnected when the backend changes.
We have production servers running meteor, with tengine / nginx as a load balancer with sticky sessions.
You can find our sample scripts here: https://github.com/ramezrafla/meteor-deployment
But do note that some sysadmin knowledge is required.
We did not use pm2-meteor, but we are using pm2 with our own config (which you can easily customize).
That’s exactly the repo on which we based our deployment script . Thank you, btw!
Beautiful! My pleasure. Any PR’s to make sure it stays relevant to community would be appreciated (if you made improvements).
Oh, absolutely. Our app is in the last leg of development and the deployment scripts are still pretty ropey - not yet acceptable for release. As soon as we’re out in the wild, I would love to add to it at least a subroutine for compiling and installing Tengine from source and one with some form of save/restore for the Meteor folder (not sure if to trust pm2 with that).
It’s a promise.
Thanks, much appreciated. We have been using pm2 for a while now and simply love it. Works great, gives us basic data on CPU and memory with charts. Our scripts use pm2 restart ... and it has been very reliable.
PS: We are also using mongo-client on server now so we can inspect the DB live. A rudimentary admin panel of sorts. Also works great. Thinking of adding that to the scripts, it just grows the scope and complicates things.