Best practice meteor deployment?

Is there a best practice for self hosted meteor deployment nowadays?

I’m moving a project to a new server, the old one is running on CentOS/Plesk/Passenger but I’m considering towards Ubuntu/Mup.

Which OS most used for meteor? I’m now running on CentOS but this has given me some meteor specific problems already which would probably wouldn’t have happened on Ubuntu.

Mup? mupx? pm2-meteor? meteor-now?

Thanks.

I don’t know CentOS, I’ve deployed from scratch (no mup) with an apache server on Ubuntu without any problem related to the OS.
I’m currently writing a tutorial about my way to do it but you can check my config on this post meantime: Is it ok if http://myapp.domain.com:3000 is reachable?
Out of curiosity, what can of problems did you get on CentOS that you wouldn’t have on Ubuntu ?

Thanks I will check that out.

This was the problem I had, which is now solved by rebuilding fibres from source after every deploy:

I’m currently deploying on Amazon EC2 using pm2 with mongo, npm, and nginx. Seems to be working really well.

1 Like

Which Linux OS do you use on EC2?

Sorry, I meant to say Ubuntu 18.04 … I wanted to go with the newer 18 so i dont have to change anytime in the near future. I run Meteor 1.8 and node 8

1 Like

I used to do manual deploys on an ubuntu VPS, behind nginx, but mup is so much easier.

I can be useful to know the steps in a manual deploy, but really you should just save the time and go with mup

here it is :crazy_face: Tutorial: Deploying meteor app on vps/dedicated/own production server

I googled your error and I definitely don’t want to try CentOS :face_with_raised_eyebrow:

Nice tutorial, some questions: Is there a reason you chose mongodb 3 instead of 4? And no recovery/restart for application crashes?

Thank you.

If I remember well, I’ve just apt install mongodb thinking that I got the last version, it probably works with the version 4 (feedback appreciated).

As a first meteor project (and first webapp in real production), I wanted to do it simple, without extra feature for the moment. That’s why I didn’t like the tutorial from passenger because it requires to dig more again in another yet javascript package and documentation although I just wanted to publish the app at first and then update it according to my future needs.

For what reasons the application would crash ? What would be a simple way to add a recovery/restart feature ? Something like a script tracking the pid and trigger a new node main.js/npm start if needed ? Or perhaps there is a “npm way” or a “meteor way” to do that ?

Just to share a different opinion: I am running production on Ubuntu Server with Phusion Passenger and nginx. There were no issues at runtime within a year, passenger is very reliable and autostarts on server startup and recovers on crashes. Besides there were no crashes since the app is not too large and code is quite stable now.

I think the issues you had were more CentOS related.

The creators of it would wish you to use Galaxy hosting, which is custom built for it: https://www.meteor.com/hosting it’s not cheap but makes you feel good since you’re supporting the people who make Meteor.

2 Likes

If I would work in a company that would be the first choice. But in the public sector you won’t get a confirmation on that pricing plan, especially if you consider that it requires an additional Mongo hosting plan as well… And the time saving and support service is not considered to be an argument :-/

I decided to go with:

  • Ubuntu 18.04
  • pm2 and pm2-meteor
  • nginx
  • Mongo

Got it running for a few days now, going smooth so far.

2 Likes

The ‘best’ way depends on your knowledge and comfort with various technologies, willingness and ability to learn and debug new things, how much DevOps experience you have, what are the goals - quick setup vs flexibility, scalability vs ease of use etc.

You can :-

  • setup a quick server on DigitalOcean with mup.
  • manual setup with node/pm2 on Ubuntu.
  • move to AWS (or other cloud) with multiple EC2 instances, then add a load balancer (nginx/ALB) in front, then do SSL termination
  • setup autoscaling with Beanstalk
  • start using containers and move to ECS
  • remove the manual management and move to Fargate

This is just for the actual Meteor app :slight_smile: Of course you can decide to also pay a Meteor hosting service like Galaxy.

There are other components like Mongo, Redis-oplog, Kadira/APM, or any other microservices you might want to use. Each of these has multiple options, self host vs paid, combining servers, going serverless (Lambda) etc.

Most of these are not unique to Meteor, which in the end is just a node app.

I am running 3 meteor apps with following configuration:
Server: AWS EC2
OS: Ubuntu 16
Mongo: locally hosted
Deployment tool: mup (http://meteor-up.com/)

For small projects, mup is super easy and recommended. I have written a small write up on this, please read it once: https://medium.com/@sourabh_shankar/why-use-meteor-up-mup-to-deploy-your-app-9c65e6da434a

The most important thing to keep in mind while using mup, is to use correct docker image for correct version of Meteor.

1 Like

Do you just have one server? What are you doing for horizontal scaling? The user-experience when deploying a new version?

I’m interested in getting off Galaxy but haven’t nailed down the best solution that has the easy horiztonal scaling and user-experience when deploying a new build that Galaxy offers. Any thoughts?

I was always puzzled why MDG didn’t offer their own Mongo solution inside Galaxy. They were already doing so with the intial free deployment option, and you can’t beat the ease of meteor deploy if you get a scalable DB automagically :man_shrugging:

Two Galaxy deal breakers for us:

  • No data center available near our users
  • No Mongo

edit: The price for us would have been irrelevant, 9€ or something per container per month was very much ok.