As recently as 6 months ago, I used mupx and it worked fine. With the latest version of Meteor, none of the Mup or Mupx deployment scrips work. Seems to me they are all dead.
I’ve spend over 5 hours today trying to deploy my app to DO using Meteor Up, Mupx and other variants and none of them worked. The closest to working is Mupx, but it stalls on the last step because, apparently, it only installs older versions of Node, which Meteor 1.4+ are not compatible with.
So, what options do I have left on the table for Meteor app deployment? Seems like the once popular methods are all dead.
I use a shell script to clone my project source and build it on the server (now with npm install too).
I use forever to start the node.
I use Nginx to proxy the port for the websocket and handle the public assets request.
You have to install/setup mongo manually before.
and finally i just add a little shell script to my rc init to restart the node in case of reboot et voilà
That feel when you have to be an experienced systems administrator to deploy a Meteor app.
pm2-meteor is floating my boat at the moment. Doesn’t have the
mupx setup, but it’s
pm2-meteor deploy is just as easy as
I got into a tight spot the other day with the home-grown deployment strategy I’d been using for the last year for one of my apps – it broke with some updates I made to node (4.5.0 -> 4.6.2), I think. I don’t really know because I couldn’t be bothered trouble shooting and knew I could (and did) have the site back up within 20 minutes using
Yeah, that’s actually what I just found and I’m going to give it a try. Seems stable enough and has scaling ability that Mup didn’t have.
If you don’t want to have devops or the bare minimum of it, go with Galaxy. They are great.
It’s worth the money.
If it’s just QA server you can turn it off, if it’s production but only a few users get the smallest instance.
Galaxy and MongoDB Atlas are great together.
I second Galaxy. If it’s a serious SaaS that will be pulling in revenue for you, I wouldn’t mess with anything else unless you have the time to do DevOps, or have someone to help with that. I’m using Galaxy + mLab and it’s a breeze.
pm2-meteor sounds great for smaller/hobby projects, thanks for the tip!
I don’t think you need to be an experience system administrator. I am surely not.
I use similiar setup.
This is my step
- clone my project source and build it in my build server (this contains the configuration)
- create a new production box (with rc.init ocnfiguration in it)
- tarbal the result and transfer it to my production server
- unpack and install dependencies (npm install) - this usually takes time
- start meteor server
- confirm the meteor server is started and then switch the connection in load balancer from old box to the new box
step no 2 and 6 is needed when you want to have minimum downtime on your time.
but if you can afford to have your app down while waiting for step 4 and 5, then step 2 and 6 is not necessary (less money to spend as well).
oh ya, all of the step above is done automatically by jenkins. it triggered when all of the test case for my app are OK. so I just need to push my master branch to gitlab after I merge with my dev branch.
Or you can pay for Galaxy, a lot simpler than my step
I recently went with Passenger Fusion they have great tutorials on meteor.
I wrote a Shell script to deploy my meteor app with update restart and all works pretty well like MUP
how much are you paying monthly for Galaxy?
Did you try my fork of original meteor-up? I use it to this date with Meteor 1.4 and it works fine.
Yeah, but I get an error that reads something like this:
config.js:89 return location.replace('~', process.env.HOME);
I would need to see the whole error, but I got reports that it stopped working with Node 6.x on your local dev machine. It works fine with Node 5.x.
This is the full error when running mup setup:
return location.replace('~', process.env.USERPROFILE);
TypeError: Cannot read property 'replace' of undefined
at rewriteHome (C:\Users\ayy\AppData\Roaming\npm\node_modules\mup\lib\config.js:89:20)
at Object.exports.read (C:\Users\ayy\AppData\Roaming\npm\node_modules\mup\lib\config.js:73:38)
at Object.<anonymous> (C:\Users\ayy\AppData\Roaming\npm\node_modules\mup\bin\mup:20:23)
at Module._compile (module.js:409:26)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Function.Module.runMain (module.js:441:10)
at startup (node.js:139:18)
It seems you have something wrong with your
mup.json configuration file. From the stack trace it seems that you have
ssl option enabled, but you didn’t specify the
pem option which should point to your SSL key.
Pem option is defined like this:
Maybe it needs an absolute path without the ~?
Whole server portion is set up like this:
Do you have a
ssl field somewhere in the config file?
Yes, there’s an SSL field:
"certificate": "./ssl.pem", // this is a bundle of certificates
"key": "./www_mywebsite_com.key", // this is the private key of the certificate
"port": 443 // 443 is the default value and it's the standard HTTPS port
According to the docs this is not correct. It seems you are using config structure from the new meteor-up, while my fork uses “classic” meteor-up. You need to specify a
pem field inside this
ssl field for SSL support to work.