I’ve been wondering the opinion of other meteor developers out there on which method you use to deploy your app and why you use it, pros and cons, etc.
I myself have used all of the above and have more experience in this order:
Manual deployment:
I’ve been using this method for the following reasons.
My apps are big in size and I only have 1mb upload bandwidth, so if my app grows bigger than 100mb… well you get the point.
I mostly use an ubuntu server in digitalocean and the way I evade the upload issue is using git in the server so I just do git pull and build the changes.
But this process takes quite a while and if I can avoid it, I would(my opinion)
The other method that I’ve used a lot is mupx:
This one has been the best option for me for quite a while, but the issue with mupx is that it requires you to upload the bundle every time you make an update which for me can be frustrating when the app grows in size as I don’t have a fast upload bandwidth.
Same with Galaxy (I have only tried it once or twice, I’m not sure if it has changed)
I must say, it is pretty straightforward, and I get to deploy my app in a matter of minutes.
It also doesn’t require me to upload the entire bundle each time I make an update as it works with git push heroku master and heroku takes care of the rest for you.
If you don’t have money to hire dev-ops or are not into dev-ops yourself Heroku is really the only way to go. It’s much more reliable than Modulus and can scale well (I have 5 or 6 prod apps running there now… all have migrated from using MUP and Modulus).
The real winner for me is the free continuous delivery pipeline feature. This is very time consuming (and possibly expensive) to setup on your own. It also guides you down to using best practices for software engineering. You setup two apps, myapp-staging and my-app-production and then add them to a new Heroku pipeline. Then setup the pull request support which copies the staging environment and creates a temporary app for testing your changes.
The flow goes like this:
create a feature branch off of master, eg sg-endless-feed
do work in this branch until feature is done
submit a pull request to your own repo (easiest to do in the GitHub GUI app)
Heroku notices the new pull request and makes a new app myapp-staging-pr-3 and the link is added into your Github pull request page. This way you or others can preview your work remotely
Make changes as needed and re-sync your work and Heroku will re-deploy on change
Once you’re happy with the changes merge the pull request on the Github pull request page
Heroku will (be default) auto deploy master to myapp-staging (triggered by the changes from PR merge)
Now you/team/clients can try out the app in the staging environment and ensure that all is working well
Once staging is working (and deployed successfully) you can click the ‘promote to production’ button on the dashboard and Heroku will take the precompiled slug and start it in prod… in seconds (you can also auto deploy if you wish)
Manual deployment: very bad idea for the vast majority of people. Just a huge time sink and very easy to get wrong.
MupX: my current favorite solution. The only problem is that it doesn’t handle scaling automatically, so you have to set up a load balancer yourself.
Heroku: I haven’t tried it recently, it’s been hit-or-miss in my experience but it’s certainly easy to use. Not having to upload the whole bundle is a plus. Not sure how it handles scaling.
Galaxy: would probably be the best option, except I ran into some memory leak issues with Nova when I tried it. The issue went away once I switched to React Router SSR instead of FlowRouter SSR, so I should try it again.
Scalingo: I haven’t tried it in production myself, but it seems like a better, more Meteor-focused Heroku.
To recap: for small, “toy” apps I’d recommend Heroku or Scalingo, for larger more serious projects MupX or Galaxy.
Galaxy has been a breeze for me. Just way too easy to scale and built by the smart people at MDG (enough said). They’re going to keep building more stuff for the platform so should keep getting better.
In addition to the deployment options listed above, another popular option is NodeChef. NodeChef offers high quality deployment platform for apps. It encapsulates a production database so you don’t have to rely on sandbox databases especially for production apps. And it is well priced to cater for apps of any size.
Modules: Promised to be the best Meteor host at the time but had some reliability issues. An update on their side killed our production app once. I think they improved it by now, but we stopped using them after a couple of issues.
Galaxy: Only been using it for internal projects, just to test it. Still feels a bit immature, although it’s been stable so far. Basic features like setting ENV variables (like at Modulus and Heroku) or updating your payment details are still missing in the interface.
Heroku: For me THE option for a mature Meteor host. Our production apps have been running smoothly on it for years. Add the Meteor build pack and your good to go. Has all the Meteor features you need, like session affinity and good rollout options plus the long list of features mentioned above by @SkinnyGeek1010.
As a Meteor fan I really hoped that my winner would be Galaxy, but Heroku has all the same features and more. Except for automatic LetsEncrypt support, but we have our own certificate… And starting at $7/month it’s a no brainer for me.
It’s super easy! On circle you can just signup and select the target repo, you can create environments variable to use during the deploy and link it with external services, like slack, to obtain notifications about your build/test/deployment process.
In the machine section you can choose what software versions you need preinstalled on the machine during the build.
In the test section you can specify your test commands.
In the dependencies section you can specify commands that will be executed before everything else. So here i’m installing meteor and a forked stable version of mup with “–server-only” build flag (mandatory if you want to deploy a cordova app, since you need this to build cordova web bundle without any ios/android SDK installed on the circle machine and to automatically publish the cordova manifest that is used by the cordova app to handle hot code push)
In the deployment section you can choose what branch will be deployed on new commits/merge and the deployment commands. Since i crypt all the deployment sensitive data on github, i prepend decrypt commands before mup.
CircleCI is free under 1500 build minutes per month (i’m deploying to 2 servers and it takes about 10 minutes)
Docker and deploy anywhere. Your own co-lo, the cloud, aws, blah blah bla.
It seems like some guys are sweating the DevOps stuff yet committing to learning a massive set of technologies, not only in terms of tools (webpack, gulp, jspm, meteor-tool etc.) front-end libraries (React, Angular, Vue, Riot, etc.), structure (Redux, etc.), methods (subscribe, watch, isomorphic, etc.), etc…
DevOps is just not that complicated. One you learn it, it doesn’t change every week. Seriously once you can route Websockets through a load balancer, its the same thing always. Once you figure out how to use Docker and Kubernetes, that its, heck, start your own Galaxy.
Yes, its challenging, so is SQL, but they simply don’t change. Learn shell scripting instead of [insert flavor of the month], even three days of it and you’re pretty solid.
I understand the “I’d rather work on my app” mentality but only to a degree. There is a balancing point where knowing this stuff helps you work on your app more effectively.
I agree completely, but I think the key difference is that if you get stuck trying to build out a feature, your app and users suffer only in the sense that they don’t yet have that feature. If your deployment strategy breaks, then you are probably scrambling, regardless of whether you diy, use a service, etc. Once you’ve had that fear in your heart once or twice, a service like Heroku or Galaxy can look very appealing, especially if you’re running production with paying users.
That being said, if you take a bit of time to get to know DevOps, even if your Heroku app goes down, you can deploy manually to AWS, DO, etc. But you still have to take the time, as you (@Babak) pointed out.
I agree that it’s an important skill to learn but using those skills come with tradeoffs. Heartbleed is a good example. Once that breaks are you able to update dozens of servers yourself? Do you have the time to keep the server OS patched and up to date? Is it cheaper to let Heroku do it for you? Typically clients will save money by having Heroku handle this instead of having me do it (and Heroku can do it better IMHO).
Also lets not forget that if you’re rolling this yourself you’re likely completely dependent on MUP unless you can setup Forever, handle rollbacks for bad releases, SCP’ing or pull down and compiling your app, etc…
IMHO it takes more than just 20-30 hours of learning in a vacuum to be able to do as good of a job as a PaaS (Heroku/Galaxy/etc…). Getting them to work and making them work well enough/reliably to operate business that can lose thousands of dollars when down are two different things.
Just my $0.02! I still think these are things that should be tinkered with, and used on hobby apps, even if you don’t use them in production.
I see your point. About heartbleed–how hard is this anyway?
With proper abstraction, all of the dozens of servers mirrors of each other and updated with a few commands.
Heroku is also more costly than intelligently utilizing Spot Fleet, etc. Another way to look at “I’d rather focus on my app” is this: I’d rather have more money to put into my app. Viz.-- development, design, marketing, advertising, etc.
Consider this for a “hobby” app: an m4.large spot instance costs roughly $15 a month. Spread that over three regions and load balance, you’re looking at like $50/month for serious power and triple redundancy. Sure spot fleets go down, but its really unlikely all instances are going down together if spread across regions. Furthermore, you could serve the front-end JS portion of the app on CloudFront.
With a little thought, for under $100 someone can have a pretty serious setup. Heroku can’t touch that. Galaxy can’t touch that. It’s worth learning.
‘Modulus deploy’ runned quite well to me. One line of code and all running. Database included. Need to say that the non inclusion of database is the only thing that keeps me out of Galaxy. I’d really like to deploy on Galaxy, but until it offers an integrale solution i’ll stay at modulus.io
Yep I agree, that would be a killer combo. The multi region is especially enticing as the only way to do multi region on Heroku that I know of is to use Route53 and multiple apps on different regions. Using EBS is also a nice feature once you have multiple instances. Though I think Apollo will help to greatly reduce the amount of servers needed.
One nice site to learn these is CBT nuggets as they can really dive in deep (on my short list of things to get into): https://www.cbtnuggets.com/search?q=aws
Regarding @jsantana 's pain point of compiling apps locally and uploading a large bundle… you can continue down the manual deployment path and write some scripts so that deploying is a one line command. Looking at MUP source code would be a good starting point (as well as writing down everything you manually have to do).
This is very convenient on day 1 but be aware that having your database in Modulus makes it very hard to switch hosts. You would have to migrate all of your data over to a new host in that case. Also more importantly Modulus and MDG are not spending all of their resources and knowledge on maintaining databases while a dedicated database host only focuses on keeping your data. IMHO the odds of having better DB perf and support are way higher with a dedicated host. My personal favorite for Mongo and RethinkDB is Compose.io as they’ve worked out really well for me (I’ve also used MongoLab and Compose for Mongo DBs).
Here we’ve been using mupx for our oldest production app and galaxy for our newest. mupx is great but I’m a little nervous relying on 3rd parties and each release of Meteor I have to wonder if I can update and still deploy with it. Galaxy has being improving steadily and the SSL integration was a big win. So I will be migrating the mupx app to galaxy soon I think.
After reading this thread through I will definitely be looking at Heroku and also CircleCI. Thanks @SkinnyGeek1010 & @siphion.
After initial deployment via mupx or what-have-you.
If your upload speed is the problem consider building a simple second level file watch (like meteor does) of your build dir to scp only the changed files to the server or a free file sync app via sshfs link. Putting said script on the deployment server to build from the source if it’s all minified and merged for single file deployment might save you time but this would be much better on a staging server, which would save on these concerns. Then deploy the slower way to production if nessecary.
If you just use raw js files during staging (no real build process) you can reload the client after pushing changed files via scp or similar sshfs mount. Anyway it seems if you can’t setup a local dev environment sufficiently and upload speed is a problem and you can’t also alternatively run a staging test server environment it seems like a possible solution to me.
It should be possible the deployment system is smart enough to git the release from your repository automatically and your development environment is beyond a sufficient simulation maybe with load testing ability etc. Once a new release is pushed and maybe a signature signed to authenticate etc. a rolling update is self triggered via git notification API.
Alternatively maybe consider a faster connection?
I’ve not studied Heroku.
